Ask HN: Are knowledge-requirements for senior engineers becoming too much?
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.
45 comments
[ 3.1 ms ] story [ 108 ms ] threadIf 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.
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!
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.
Or you can be like the person from yesterday's thread who was very proud because they hired somone without an interview.
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.
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.
Staff, Principal, Fellow, or Manager.
Seniors also exist in college and high school.
(I kid, but I also suspect there’s a tiny bit of truth in there)
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.
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 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.
I also do a lot of tech interviews and I’m shocked at how poorly people do at even basic Codility tests.
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.
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.
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!
Does work actually get done? Genuinely curious. I don’t think that many experts could reasonably come to consensus on much of anything!
Worse, those who are well-qualified.
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.
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.
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.
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.
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.
lol
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.
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.
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.
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).