[HN Gopher] Ask HN: Are knowledge-requirements for senior engine...
___________________________________________________________________
Ask HN: Are knowledge-requirements for senior engineers becoming
too much?
I work currently as a "senior" swe and my duties cover a wide range
of technologies and non-tech related stuff: Elixir, Go, nginx,
mysql, Docker, debezium, Kafka, Terraform, Ansible, HTTP APIs, a
bit of Angular, mentoring, hiring (tech interviews), product
discovery, design docs drafts, etc., etc. When it comes to hiring
senior software engineers, my company and peers seems to put a lot
of focus on the following topics: - does the candidate know about
performance, scalability, and high availability topics? - does
they know about infra topics like: K8s, monitoring, CI/CD - does
they know about GCP or AWS? - are they available to be part of our
on-call rotation schemes? - can they mentor more junior engineers?
Not to mention of course the more classic requirements for senior
software engineers like: actual working experience on the field,
solid knowledge of the fundamentals of comp sci/soft. eng., good
practices, problem solving skills, good communication skills, etc.
When I interview candidates, I try to focus on the second group of
requirements. I want to see if the candidates are able to
communicate effectively while working on a technical solution. I
could care less about details like GCP, Ansible, the programming
language they master the most, or whether they use K8s or not.
These technologies can be learned, if required. My company, though,
doesn't like my approach and they insist on me asking very specific
tech questions. What do you think? 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.
Author : sdevonoes
Score : 46 points
Date : 2022-03-12 13:19 UTC (9 hours ago)
| ComradePhil wrote:
| 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.
| xorvoid wrote:
| 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.
| fendy3002 wrote:
| 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.
| wirthjason wrote:
| 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.
| treeman79 wrote:
| 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.
| hackerfromthefu wrote:
| 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!
| neurotrace wrote:
| 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
| hn_version_0023 wrote:
| > 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!
| faangiq wrote:
| Salaries are going to double. Elite engineers are underpaid and
| impossible to hire.
| wagslane wrote:
| 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.
| eyelidlessness wrote:
| 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.
| PragmaticPulp wrote:
| 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.
| devoutsalsa wrote:
| 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.
| hackerfromthefu wrote:
| 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!
| ericmcer wrote:
| 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.
| jchonphoenix wrote:
| There are senior engineers at FANG with 3 years of experience. So
| no I wouldn't say it's too much
| almost_usual wrote:
| 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.
| ilaksh wrote:
| 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.
| ravenstine wrote:
| 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.
| lupire wrote:
| > scare off those who are underqualified.
|
| Worse, those who are well-qualified.
| d_watt wrote:
| 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.
| chrismeller wrote:
| 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?
| hn_version_0023 wrote:
| 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)
| hackerfromthefu wrote:
| 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.
| lupire wrote:
| > 20 years of experience?
|
| Staff, Principal, Fellow, or Manager.
|
| Seniors also exist in college and high school.
| mavelikara wrote:
| > 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.
| krnlpnc wrote:
| 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.
| treeman79 wrote:
| Some people can talk really well but scoot by on their teams
| efforts. Need something to weed them out.
| wilde wrote:
| I haven't seen any good data that shows that the current
| system is actually good at doing that.
| chrismeller wrote:
| 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.
| jstx1 wrote:
| 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.
| durnygbur wrote:
| 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).
| nonrandomstring wrote:
| 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.
| lopis wrote:
| 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.
| ddaalluu2 wrote:
| 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.
| cargoshipit wrote:
| "backend can be generated and requires minimum modification for
| authz"
|
| lol
| cowanon9urur wrote:
| 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.
___________________________________________________________________
(page generated 2022-03-12 23:01 UTC)