Are knowledge-requirements for senior engineers becoming too much?

Those requirements you listed don’t seem demanding at all, assuming you’re not expecting everyone to be expert-level in all of those topics (e.g. being both an AWS and GCP expert, or even an expert at either of their job isn’t devops)

If a company’s requirements are so strict that they can’t get anyone hired, they either need to loosen the requirements or raise the compensation.

Loosening requirements can open the company up to a wider range of candidates, but it also opens them up to more bad hires. If the company isn’t good at PIPing people out or the managers don’t have the stomach for letting people go, this is disastrous. Your good employees will resent it and leave.

> We currently are hiring "Go senior software engineers" (that's the actual job title in Linkedin), but I couldn't care less if you know Go or not when you come to work with me. I want to know if you are good at solving problems

It’s possible to hire good engineers who don’t already know your programming language, but it will add significant ramp-up time. Even the best engineers don’t pick up a new language and associated libraries, idioms, practices, and quirks overnight.

You can open hiring requirements to people who don’t already know the language, but practically speaking you’re subtracting 6-12 months of productivity once you account for ramp-up time and mentoring requirements from the team. You may not mind, but the company probably isn’t interested in paying $200K or more in combined salary, benefits, and ancillaries when they could pick a little more picky and hire someone who already knows Go.

I don't think these skill lists are too demanding in scope. They're too _specific_.

The list you give looks like a gamut of stuff an active dev would pick up in about 7 years. But that list would likely not intersect with a similarly competent engineer also with 7 years of experience.

On the other hand, a junior developer who needs just three or four things, say; SQL, Python, Git, JS - would more probably intersect with another junior role in a short time-frame of say 3 years.

So as engineers get older, and the list of things they've done gets big, what is the likelihood it will match some specific subset in a world that is advancing and expanding so fast?

After 30/40 years I can list over 20 languages I've learned. Truth is, after about number 10 they're all more of the same thing and you start to forget the details anyway.

When I've been the guy doing the hiring, I never put much weight on exact matches because the probability of that intersecting with a _specific_ senior candidates skills is practically zero. But I do take note of _breadth_ of knowledge.

Sounds like they want a devops person and not a developer. I understand the line is often blurred. I think it comes down to if the role is deploying K8’s etc. or just using it. If they are administering it then I’d hope that they would be able to answer those questions.

Good teams contain a balance of skills and abilities. It’s not unreasonable to want someone stronger in some areas than others to compliment the team. A diversity of talents also helps so that people teach each other.

Probably one of the questions here is how your company defines Senior. I’ll assume we actually mean “senior” and not “We give out senior to anyone with more than 3 years of experience because the title make it easier to hire.”

I don’t think those requirements are very much for senior. The first four bullets are “can you own your code through into production,” and the last one is critical to build a healthy organization that can build up new people.

Honestly, if anything I feel like there’s a trend to expect less from developers because the market is so tight, you can’t push people to grow for fear they’ll jump ship. Many developers are allowed to become “advanced beginners” where they’re just getting really good at one small part of the stack.

And if that’s all you want, to be a badass (React Dev | Golang Dev | SRE) etc, that’s fine, but unless you’re truly at a company massive enough to support deep specialization, that’s not being senior.

Interviews are largely broken today. People don’t write code in front of other people in real time in their jobs. They write it for an interpreter or compiler, and huge amounts of time and resources are spent building/maintaining development environments and pipelines. Trial and error is engrained into the normal workflow. It baffles me that a few minutes in a share notepad is commonly considered an accurate gauge for skill.

I think a much more accurate way is to discuss the role and candidate background and experience, and if theres a fit invite then to participate in code reviews and/or a small project.

Companies are cheap though, so they would rather do quick and crappy trivia interviews than something more time consuming and thorough.

Many big companies address this by interviewing for problem solving, communication and system design instead of interviewing for a specific list of tools. And many people hate those interviews. I still think it's better than going over a checklist of technologies.

Or you can be like the person from yesterday's thread who was very proud because they hired somone without an interview.

Wow. I would never work for you / your company. I avoid those job descriptions like the plague.

I've been working in the field professionally and self employed since 2001.

I moved from PHP to Go in late 2013, because Google+ hype and it felt such a relief when working with Go vs. the PHP craze that was happening at that time.

I hate k8s with a passion as do I dislike everything cloud for being too expensive and overly complicated. I see k8s as a cloud lockin tool. It's so complex that you can't properly run or maintain it. Have fun debugging problems. Your everyday problem doesn't require a cloud exclusive solution. A single Go server can handle a good 500 million visitors per month.

I do Angular as well but have moved to Vue since about a year ago. And recently I'm getting into learning native Android development with Java. Holy crap what a shitshow that is. Old technology new emerging technologies all mixed up and no real standards.

I like backend but let's be honest, backend can be generated and requires minimum modification for authz/n. The real work is in the frontend.

When I see job descriptions like those I think "this company is too cheap to pay 5 people and they want to work you to death and unhappiness for the same cost".

Add to that the "agile" method.

I love working with Go and I love a change of focus, work on backend for a few weeks then on frontend for a few. What I don't like is doing the work of 5 other people but getting only 1/5 of their pay. Also hate the whole "ops" Hipster bs babble. To this day idk what DevOps is. It's all just bs talk to avoid telling the truth of what they really want you to do.

I think job requirements evolve based on who is available in the market, and based on how quickly and how willing a typical hire is to move to your tech stack. If people with specific experience are available, companies will tend to hire those first - lower risk from their viewpoint; otherwise training becomes a necessity.

Expected tenure is also a big factor - if a company seeks to recruit long-term employees than the criteria will be very different: they will focus more on ability to learn and adapt, team work, communication skills and leadership ability than on short term tech stack.

I kind of agree with you. I don’t care if a new hire has deep experience in every part of the team’s tech stack. In interviews I look for four things:

1. Do they know the fundamentals of each domain they mention in their job application? How well do they understand and how well can they explain core concepts?

2. Do they have an attitude to learning and teaching that will make it possible for them to pick up the gaps between what they know now and that they need for the job? Will they be able to keep going past that? Will they be able to support co-workers on their journeys?

3. What are the specific gaps between what they know now and what they’d need to know to work in our tech stack? This isn’t to exclude them from the role, more to understand what support they’re going to need and what the ramp up might look like. I try to keep it away from trivia and more general. Eg. “tell me a time you had to debug a problem in go code. What was the initial bug report and how did you get from there to solving the problem? What did you do to make sure it didn’t happen again?” Those open questions can lead to some good conversations and give a good sense of how well a candidate understands an area.

4. By now I’ve made my mind up about whether I’m going to say yes or no. Now I see if I can convince myself the opposite (without being a jerk).

I don't know your specific situation, so I'm just guessing various scenarios... which I hope will be of some help.

Maybe the problem is that your peers are short-sighted or it could also be that your understanding of organizational resources and capabilities are limited.

For example, if we are definitely using Golang for the forseable future and I can expect some slowdown from hiring someone with no previous exposure (because they will be spending some time and resourced familiarizing themselves with the syntax, tooling etc.), I would like to be able to make that as a part of the hiring equation... and be able to decide where to filter them out in the various stages of the recruting process... depending on various factors.

For example, are you struggling with enough quality applicants because of having stricter requirements? Do you think loosening the requirements would potentially bring in people so much quicker... or bring in those who are so much better that they can potentially make up for the time and resources the company would have to spend to make them productive?

Another possibility could be that these things are not easy problems to undertand given your current resources or insights available to the hiring team... in which case, you would have to have strict requirements just to be safe... or take informed risks accordingly.

Also, if you don't have the influence to make your peers see that, maybe it is not your place?

Again, I can't know your situation so I'm playing with various hypotheticals here. Take what applies to you (if it does) and discard the rest.

The list of technologies and responsibilities makes me anxious even though I held senior roles few times. My one workplace in fact was so demanding - it had high employee turnover and I left it with a bang. If I had the ability to sport these efficiently for 8h per day and 5 days a week (but I doubt 40h is sufficient in such workplace), I would prefer to set up various personal projects yielding passive income and capital gains (stocks, crypto, ads, whatever).

So… “senior engineer” to me means becoming a leader that knows how to forge a path through the forest of unknown unknowns. It means that the person is capable of navigating an org structure. It means that the person knows how to balance the endless mutually-incompatible competing requirements. Etc, etc, etc.

See what I didn’t mention? I don’t care about trivia knowledge. Tech knowledge can be so fleeting. What doesn’t change is good judgement and good leadership.

Job requirements are meaningless. They've always listed a bunch of skills you may or may not use to scare off those who are underqualified. Hopefully few companies actually believe there's an engineer capable of being good at everything from devops to frontend.

To me there are two core issues reflected in your question. Fundamentally your manager does not understand programming, and fundamentally they do not respect your judgement in hiring or how to hire.

Most good programmers are going to use Google to check on relevant information for their problem, even if it's related to a language or area they are relatively familiar with. That just because of the nature of technical problems, software and Google. So not pinning your hiring on detailed recall of specifics in an interview without allowing Google is just reasonable.

I feel like it is. Aside from programming language and database, at least there'll requirement about AWS/GCP and docker. (On a side note, why do we need to know AWS/GPC anyway? With unlimited budget they're piece of cake for user level. For optimization, it's better to hire one specialize in it)

However if it's not lead position, anything except programing language and database isn't a deal breaker.

However the more absurd is one that need project management / task assignment experience and/or tdd or test automation.

It's funny, I've experienced the opposite, usually in the form of the "senior" title being handed out as a retention incentive because the company doesn't _really_ want to pay more. Here's a senior title and a 5k raise sort of thing.

That said, I agree that these requirements sound too specific, but they don't sound too intense. I mean, After working in the industry for ~8 years I would expect someone to at least be familiar with a bunch of this stuff.

When I’ve been in a position to consider senior candidates, what I look for most:

1. Do they either have a diverse breadth of experience, or a depth that suggests similar ability to expand their knowledge?

2. Do they communicate effectively about how they think about problems, and how they approach solving them?

3. Do they show sincere interest in the problem space? (This becomes top priority if the problem space is a social good.)

4. Can they reasonably demonstrate that they’re competent?

5. Are they motivated to balance team priorities and quality improvements in a way that benefits both?

Specific technologies almost never enter into it for me. I’ve never seen a competent senior engineer both want the job and fail to adapt to its technical details.

There are senior engineers at FANG with 3 years of experience. So no I wouldn't say it's too much

I imagine it differs between roles and companies. Some jobs I have felt comfortable with my knowledge level within a few weeks, at other places I am frantically learning things for my entire tenure and never feel completely comfortable.

Requirements for seniors is technical leadership and communication. They’re good at understanding complicated problems and have encountered them before. They can identify key pieces of larger problems based on requirements, and can break them into smaller chunks of work.

With that they communicate succinctly to others via specs and rfcs.

If you’re in a specific domain like network protocols, operating systems, or performance engineering more domain experience will probably be required for the role.

Languages and platforms (AWS / GCP) don’t seem as important as they’re well documented and easier to pick up than the skills above.

Salaries are going to double. Elite engineers are underpaid and impossible to hire.