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 loosening requirements necessarily leads to bad hires. If anything, it may lead to access to better hires. Think about an old tech stack that’s kind of boring. Likely no good engineer is sitting around actively learning Java 6 on nights and weekends, at least not with the intent to seek a Java 6 position. If you limit yourself to people who actively work in your anachronistic tech stack, you may be limiting yourself to only the people you don’t want to hire.

There’s no way 6-12 months just to get up to speed in go. If you’ve been working in a relatively similar domain (ie webdev) and have access to teammates with experience in go (to review code and expedite your learning) it shouldn’t take more than a month or so to be a net even at least and growing rapidly. And even then, an experienced devs other contributions outside of code should more than make up for some slow coding.

A month is enough for a technology or two. But we are talking about developers that are supposed to use like twenty different technologies at the same time, and maybe need to learn five or seven of them.

And often the reason a company wants one person to use twenty different technologies is that they can hire as few people as possible. Which means, there often isn't a more experienced colleague at the workplace to learn from. And no, the company is not going to pay you a training either.

Go is one of the better languages for upskilling on the job.

Realistically learning syntax of most languages doesn't take too long. If the new hire has a good grasp of all the Concepts/Techniques from comparable languages, that would not take too long either, and then you're left with learning environmental aspects only such as libraries and toolchain.

I've personally picked up a new language in a job many times with learning time of a month or two to be pretty much as effective as the majority of the team.

This only works for some people, but what worked for me is while starting reading the language reference and one good up to date book on getting started in the language, both cover to cover.

Pairing is very effective here as well in picking up the nuances of how to use the toolchain efficiently, but youtubes can help if pairing isn't available.

That said I wouldn't take Python only developers and try to get them to learn C++ or Haskell on the job!

As a senior programmer I wouldn't like to lose that money either, just because you happen to choose a stack that is different from mine. You see, I have my Java(or whatever) stack which still makes me moolah.

A smart person with experience in C++, Java or anything similar could be pushing Go commits in a week. They’d effectively be fluent after a month of immersion.

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.

As a frontend developer, this is maybe even more true. At my first job I only used jquery. In my second job I used react. My third required Vue. If companies would be so stingy about specific tech stacks, it would be impossible to move forward.

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.

Seen some companies fail because everyone was expected to be full devops in addition to core speciality. Almost no one could get anything useful done. Mostly because kub was simply to much of a time sink.

Honestly find this hilarious, and a sign of the low experience levels prevalent across the industry, with inflated titles etc.

What should happen in these situations, is someone with enough experience should be able to say this isn't working as well as previous ways, and guide to more sensible practices that suit that companies situation.

This is very hard when 'everyone is a senior' and 'i read this blogpost lets cargo cult it'..

The older crafts industries had masters, journeymen, and apprentices, in a more hierarchical structure, and while more rigid led to much less of the kind of massive waste of effort your post talks about where 'Almost no one could get anything useful done' .. which you've seen at multiple companies!

Absolutely. I recently dropped in to a job where I was led to believe I'd be spending most of my time architecting applications but I've spent most of my time on ops stuff. Every engineer is expected to have more than a working knowledge of AWS, Terraform, and Kubernetes. I don't know how anyone gets anything done

> I don't know how anyone gets anything done

Does work actually get done? Genuinely curious. I don’t think that many experts could reasonably come to consensus on much of anything!

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.

Thank you! I’m so sick of interviewing “senior” devs that have 3 years of experience at two companies. Similarly I’m sick of companies qualifying you as senior after similar time periods. What happened to those of us with 20 years of experience?

> What happened to those of us with 20 years of experience?

If you are contributing purely by writing code for projects, it is still "senior" - maybe a senior "senior". If you are contributing a higher level value, as the sibling comment mentions, there are other titles like "Staff", "Principal", "Fellow", "Distinguished Engineer" etc.

I agree very much, a few years commercial experience really means not junior anymore, but mid level.

Most people with only a few years experience are lacking depth and well roundedness to have tried things different ways and be able to swap their approach to the circumstances. Thus they aren't that good at selecting appropriate tradeoffs and guiding to more efficient approaches, as someone more senior can be.

Instead most people with only say three year only have deep knowledge of one language without breadth, and are unaware of so much of the history and alternatives in our industry that they don't have the kind of flexibility to really make informed choices. Thus the massive prevalence of cargo culting, resume driven development, and fud in the industry.

Regarding a true senior, I agree they should have a working knowledge of the aspects mentioned, as they are about providing for the 'full lifecycle' of systems. They should also understand other things related to a full lifecycle, like TDD + integration + manual testing to provide reliable systems, and live support, and engineering systems in such a way they can be effectively supported, and how to identify requirements clearly, communicate and operate effectively in teams between the various roles etc.

Typically this comes in the 5-10 year hands on experience range, while mastery occurs in 10-15 years. However everyone is different, some people go (a little bit) faster than this and some slower. However financial incentives get most people to elevate their titles, while the actual skills take more time.

This is based on my observations of about 25 year in the development industry as a dev, lead, architect manager and director/cto. My 'opinion' of course.

I suspect that agism has forced many into early retirement or management. Its sooo much easier to take advantage of young human resources, right?

(I kid, but I also suspect there’s a tiny bit of truth in there)

> 20 years of experience?

Staff, Principal, Fellow, or Manager.

Seniors also exist in college and high school.

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.

Some people can talk really well but scoot by on their teams efforts. Need something to weed them out.

I haven’t seen any good data that shows that the current system is actually good at doing that.

Have seen metrics that show a good programmer from a bad one?

That show that the current interview system filters for “good programmers” as defined by the company’s performance system or whatnot.

I agree completely, but on the flip side you are usually applying to many jobs… writing a real example app or doing a live coding exercise for every single one is impossible.

I also do a lot of tech interviews and I’m shocked at how poorly people do at even basic Codility tests.

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.

“backend can be generated and requires minimum modification for authz”

lol

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.

> scare off those who are underqualified.

Worse, those who are well-qualified.

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.