Great article. I really appreciate that the OP describes a more closed-form solution to what makes a senior engineer, rather than platitudes like "learn 5 languages".
One nit I'd pick with it though is that many large and bureaucratic companies won't appreciate an engineer who decides it on them to fix hiring, culture, product marketing fit and marketing. If you find yourself in this position, it's time to move on to somewhere else that will. Typically, those companies are startups.
The great frustration is that the longer you spend tilting at those windmills at large companies, the less likely you are to get a startup to actually hire you, since you are too "corporate" or "enterprisey".
Well, I haven't. Just last week I had DigitalOcean refuse to even talk to me because my experience was "too government/enterprise". I imagine the dozens of black holes at similar companies I have communicated into over the past years are for similar reasons.
The types of problems experienced in mid to late stage are definitely more relevant to someone with experience at ops and scale. Late stage startups or enterprise (the line blurs) are popular places to pick such talent, and for these needs specifically, Netflix is one popular source.
Honestly, our industry has such a love affair with engineering at this point that at many companies you can easily have an impact in these areas if you're senior enough. And by "senior enough" I don't mean having a big enough title. These groups are willing to collaborate with people who show honest interest and appreciation for the problems they're trying to solve and the roadblocks they hit while doing so. It may sound a little chicken and egg, but I think part of how senior people demonstrate their seniority is to successfully work outside their silo. Unfortunately many engineers fall into one of two traps: waiting for permission to do this kind of work or -- the flip side -- barging in without having a clear way to contribute.
I'm reminded of an experience many years ago, when talking to a couple of other senior engineers about a talented but hotheaded young manager who couldn't understand why we were all so cautious about new ideas. We decided that what he really needed was a death march - the experience of being stuck on a project that is inevitably doomed, and having to push on through to the bitter end anyway. That'd teach him!
Senior engineers with the foresight and savviness to execute on such a plan are also going to be savvy enough to not allow it to exact a toll on themselves. Especially with junior managers.
Pressure will be created and focused onto the non-technical problem creator and reliefs for that pressure will be similarly engineered in precisely the same manner. All the while, the engineers will keep a smug, knowing look on their faces while the manager flounders around a technical terrain that they can't begin to fathom and that has suddenly become utterly hostile.
The manager will eventually 'get it', realizing that he has to work with the engineering team and not against them. Then all problems magically evaporate and a new understanding is reached.
Frankly, this sounds absolutely insane. How is a death march that doesn't exact a toll a death march? Does anyone work a 40 hour a week death march?
Why wouldn't you just look for a new job? Why waste your own time on a doomed project?
I certainly hope all the engineers are in on the joke, because if I found out some others on my team conspired to create this situation without letting me decide to be involved or not I would be super pissed.
Nobody non-technical knows what an engineer is really doing while he is sitting at his desk. He might be at his desk 50+ hours a week, earning time-and-a-half on top of his already lucrative salary, but he won't actually be contributing anything that the company actually needs. The senior engineers certainly won't be working more than 40 hours a week. That's for the younger fellas.
If you got handed a bunch of bullshit tasks by your senior engineer with or without a generous amount of winking and subtle sarcasm, you'd pick up on it pretty quick. You'd have all sorts of questions about why X needs to be done and would be getting no straight answers. Eventually you'd either get the picture or someone will take you aside and delicately let you in on it. Think that scene in Silicon Valley where Big Head is having his new "role" described to him, only done by the engineers rather than an HR manager.
If it looks like you need a lesson in savviness yourself, they won't let you in on it and let you flounder around just like the manager.
Oh, of course not! We weren't going to inflict that pain on ourselves...
The manager quit not long after, had a potentially good hardware startup that failed due to problems outside his control. Don't know what he's doing now, but I'm sure the startup life is better for him than enterprise.
My gripe with the "Senior Engineer" title is that I've NEVER met anyone with 5+ years experience who didn't view themselves as "senior". Usually 3+ years.
In a market where there are more job openings than employable candidates, and competition for talent leads to rampant ego-stroking and title-inflation... the term "senior" has become just another word for "competent". Someone who can work independently without hand-holding.
So how do we verbally distinguish that from, "No, I really DO mean 'senior'"? Most people get 40+ working years in a career. How do you encourage humility and self-awareness, so that people don't honestly believe they've reached the 90th percentile after the only first 10% of that journey?
Write into the job description what you actually expect from the engineer. Sadly, we don't have the shorthand you might expect in other industries, so, spell it out. "Expected to be able to drive product requirements and fundamental architecture, interact at a peer level with product and project management, mentor other team members, and make wise use of resources." Add other criteria for software reliability, security, performance, backwards compatibility, etc. as appropriate to your domain. Someone who may think they're "senior" will if they are realistic realize they haven't done that.
I work in the video games business and for us (at least at the better companies I have worked at) the title senior programmer is not based on years of experience. Usually it entails being able to work without supervision to design and deliver complicated features on time. It requires someone who is up to date with industry developments and best practises, who can take lead responsibilities but not always. Strong mentoring is another plus. I've worked with people in their late 30s that are still intermediate level. However there is a strong correlation with years and senior level, because those that stay in the business are the ones that thrive and succeed, whilst those who struggle to advance tend to quit and take more suitable work.
"those that stay in the business are the ones that thrive and succeed, whilst those who struggle to advance tend to quit and take more suitable work."
That depends on the company they are working for though. I have seen people (from tech and non-tech roles) tell me they are seniors/managers because they have X-years of experience.
More often then not, if someone needs to tell me they have X-years of experience rather than showing through example, I roll my eyes, and stay away.
> "I've worked with people in their late 30s that are still intermediate level."
At what age did they start? I've worked with people who were just getting started in their late 30s after a career change or kids growing up enough to become more independent, etc.
I worked with a guy that was intermediate in his mid 30s after around 10 years experience. Conversely there was a 50 year old guy who became a programmer after he moved to my country and couldn't practice as a doctor. He was senior after about 5 years
It's far more than the first 10%. Most engineers don't stay in the engineering track for long, and there are almost no lifelong engineers. 5 years of experience is probably closer to 50%+ of the journey.
> Most engineers don't stay in the engineering track for long, and there are almost no lifelong engineers.
That is absolutely absurd. Plenty of tech titans and small startups have architects and senior devs in their 40's and up (I'm one, and at trade conferences I'm hardly even an outlier).
Not to mention that 90% of the industry is in the "enterprise" world (seemingly invisible to much of HN's readership), which is largely composed of devs in their 40's, 50's, and 60's. The high-octane older guys often go into consulting in their later years, where they're billing at $200-400+ an hour while giving technical direction to a team of warm bodies fresh out of school (or off the boat).
If you seriously believe that engineering is something that you do from age 25 to 35, before starting your "real career" in PowerPoint, then that's incredibly sad. Why not just go the MBA route to begin with?
Allow me to offer myself as a counterpoint ;) I've worked for well over 3 years (8ish now?) and there's a lot I've yet to learn about when to take one design approach vs. another, how to identify risks early, etc. etc.
And, for what it's worth, I agree: one should not be considered "senior" after 3, or 5 years. Actually, tenure matters less than perspective and problem-solving approach.
Totally, but learning from your mistakes is not necessarily tied to years at a desk.
edit Also, we've all met that dev that just "gets it" and can be extremely productive regardless of time at a job/company/project. That dev also "got it" when they were pretty new to the industry.
I think that the number of different companies you've worked for (and the diversity in how they operate) is more important than the raw number of years you've worked. Also, how your role has grown or varied from job to job.
Rookies worry too much about "job hopping". I can't count the number of people I've interviewed who had "10 years experience"... but really they just had "the same year 10 times".
More jobs = more diversity = more experience, no? Both models are flawed I think, as 10 jobs in 10 years brings a ton of understanding of the overarching principles of working as a dev, but has a total lack of long-term team success.
2 jobs in 10 years brings an understanding of that long-term team success but a relatively small window into dev jobs as a whole.
I said that one should not be considered senior based on a time period. And then proceeded to offer two (non-time-related) characteristics I considered to be hallmarks of seniority.
The original critique was that 3-5 years was too little time (meaning time matters). It sounded like you were agreeing that after 3-5 years someone shouldn't be senior (and implying that it should be longer).
My bad. The both of you are absolutely right. To clarify:
1. I think that 3 - 5 is too short - there's so much to learn, and a lot of experience to be gained from seeing how your designs age.
2. That said, time doesn't matter as much as engagement, problems tackled, and attitude. But - it's still conditional on 1. above. You may *think* you "get" it, but it may turn out that your great designs don't age well, etc.
So, it's a combination of both. Not purely tenure, not purely attitude.
> Actually, tenure matters less than perspective and problem-solving approach.
On that token, Pragmatic Thinking and Learning is an awesome book for improving your problem solving approach, better understanding cognitive biases, and learning more effectively.
The problem is that "senior" is entirely relative to the engineers that surround the developer in question. A senior dev at Company X may not be a senior at Company Y, regardless of how many years in the industry or productive at Company X they were.
The problem also comes up for the 3-5 year mark when pay is involved. At my current company, it was impossible to make a certain salary without being promoted to Senior. The bigger problem was that the company has a slightly unrealistic view of the market, and to get any decent talent you'd have to be in the Senior pay bracket.
Ultimately I think the best solution is to screen appropriately and decouple salary from title. I think the best model would be to never hire anyone as a Senior, but let the Seniors emerge.
I've been in that company. The problem is that without any leadership, every one is a leader. The practical result of this is that software gets partitioned into the 'parts that the idiots work on' and the 'undervalued but core business logic'.
I also feel that this model of hiring is emphasized by the craze over agile (and particular SAFE) where all the engineers are supposed to be like lemmings that take orders from product owners. If you get the right team I suppose this is possible to do, but the lack of senior leadership on a team (and it's deferral to non-technical people like scrum masters and product owners) leads to unnecessary bikering among engineers on the 'right' way to solve a problem.
So I guess I don't mean "hire a bunch of devs and see who emerges as a leader." I guess in my head it works out like you already have a group of "seniors," "architects," etc. And when a new dev is hired, they don't get to just dive into the ranks of Sr/Arch. but should instead have to work to get there just like the original Sr/Arch devs did.
I don't fully understand why what alexbanks wrote implies that there is no leadership. It just means that new hires are not placed in leadership positions right out of the gate. There will certainly still be a strong leadership structure in place.
As far as I can tell, the company I'm at follows the model alexbanks described, and it seems to work quite well. We generally do not hire people on in senior or lead roles. If someone has 15 years of experience and they're a team lead at their previous job, the chances are still very high they'll have to start as a "normal" developer with us. (Notably, we do not tie salary to title. A "software developer" can have an arbitrarily high salary if needed.) If they demonstrate the capacity for leadership, we will identify that and very quickly offer them more responsibility and promotions whenever the opportunity arises.
There are many, many more developers today than there were 20 years ago. As a result, the median amount of experience is less than 10 years, which means that 5+ years actually is relatively experienced. Furthermore, I observe people being substantially more effective when they're 5 years in than 1, and again when they're 10 years in.
Really it seems like we just need more granularity than "senior" or "not senior."
I think the Dunning Kruger effect comes in here. https://en.wikipedia.org/wiki/Dunning–Kruger_effect
After 3 or 5 years you don't really know what you don't know. A lot of people think they are experts after 5. After 10 you will see all the mistakes you have made and have a rough idea of just how little you know.
The way I look at it these days is: I can manage to do anything related to an API or app. The polish that comes after the 2nd, 3rd, 5th, 10th years is just doing things more elegantly and with better tooling. For me, it's mostly been about stronger separation of concerns.
That's my perspective at 3 years into startup software engineering.
I think a large part of this is that we didn't have a technical career ladder until recently, and that a "seniority" has different meanings depending upon whether the company treats software development as a strategic business asset[0].
Now that we have technical career paths where one can expect to continue as technical individual contributor, the official "Senior Engineer" title falls roughly in the middle (slightly on the lower side) of the career ladder[1]. I'm generally OK with this personally, so long as we distinguish between the title "Senior Engineer" and the role "senior engineer". The role I would equate to Randall Koutnik's "Finders"[2].
Not official in the sense of "there is some standards committee making these designations", but it seems to be a commonly accepted practice that the title of "Senior Engineer" is assigned to someone who "is capable of being given a high level (and often vague) task, and work completely independently on it and finish it" but not anything more.
But my main concern was distinguishing between the title and the role. When I think of the role, I think we generally consider someone to be senior when they can:
a) work through very thorny technical problems and find novel solutions
b) connect technical solutions to the needs of the business
c) provide leadership or mentoring to other engineers
Like or not (I don't, personally) the title and the role use the same words but mean different things.
> Not really, as the upper levels aren't reached by most people.
I'm not clear on what your point is. Is it in the middle of most people's career? No. Is it in the middle of most technical career ladders (as used in various tech companies)? Yes.
My point is that in places where there is a technical career ladder, there are titles that do actually reflect (what I consider to be) the role of a senior engineer. This is how tech companies get around the fact that convention has lowered the expectations of the title Senior Engineer.
The core problem is that there is confusion about the relationship between title and role. The OP is trying to fix this confusion by raising the standards of the title to match the role (by explaining what the role really entails). I'm just trying to clarify the conventions set by the industry so that people can plan their careers accordingly.
I remember a guy we interviewed that was 1 year out of college and was a 'senior software engineer' because at his previous company he was the only developer. As such they made him the senior SE. The same can be said of 'Lead engineer' or 'Tech Lead' where there are 2 people in the group and you're the 'Lead' (whatever that means).
> How do you encourage humility and self-awareness, so that people don't honestly believe they've reached the 90th percentile after the only first 10% of that journey?
Why would "Senior Engineer" mean someone who is at the 90th percentile? Anywhere that gives out the title "Senior Engineer" to someone with 3 years of experience will certainly have many higher titles, so what's the problem?
I find this article fundamentally confused. The author spends a lot of time talking about what he invisions a senior engineer ought to be in his opinion (which involves all kinds of ownership). But senior engineer is just a title, it can't be used wrongly, because it's inherently a meaningless cat-and-mouse money game between employees and companies. It's politics; it's a name.
Much in the same way that somebody founding a startup can be "engineer" or "CTO" or "Software king Ninja Level 7 dan grandmaster." Titles will never be objectively consistent, this is why the whole industry is now discussing consistent interviews instead hiring based on titles on resumes.
A junior engineer is proud he got his code to work, an experienced engineer is proud of the code he wrote to get the feature to work, and a senior engineer is proud of the code he didn't have to write to get it to work.
Agreed, but small critique: i hesitate telling more junior devs things that sound like "less code is better". It is a message that can easily be misunderstood as "if i write this in a more clever way the code gets shorter" instead of the intended lesson.
I've found that for me, "code so that I can comprehend it six months from now at 2:00am after several drinks" is a good motivator for "least brainpower".
I've seen some senior engineers take this too far. It's as if they are burnt out from all the code they shipped into production that broke things. They tend to favor solving problems operationally rather than through correct code. They also favor dumping problems onto third party libraries to the point of causing more problems than they would by allowing a more specific implementation.
Some fallacies I've seen from senior engineers:
"Let's ship the simpler solution even though it has clear problems. We'll hide it behind a feature flag and deploy it to a few machines first to make sure nothing disastrous happens."
"Let's coerce a third party library to do the thing we want even though it wasn't really designed to do what we want. By using the third party library we don't have to take ownership of what we are writing! So much less code to maintain!"
The second bullet in particular can be ironic because I've seen senior-engineer-written code break production because it tried to rely on a third party library to do something without doing any unit, functional, or performance testing to ensure it was doing the right thing and doing it fast enough.
After having been in the software engineer for close to a decade, I see an increasingly worrying trend where companies just assume their engineers are incompetent and favor delegation to third party libraries, external services, and devops/metrics/monitoring to solve all problems. As someone who considers himself a competent engineer, I find the trend saddening because I'm not trusted to write correct code either.
To answer your points from the perspective of a senior.
1. "Let's ship the simpler solution even though it has clear problems." You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely. Shipping the simpler solution is a way to test the waters and make sure you're building what is expected or wanted.
2. "Let's coerce a third party library to do the thing we want even though it wasn't really designed" Same point as #1. Whats the easiest way to get something out so that we can test and measure assumptions.
Overall if you've read the article its about reducing risk. I don't want my team to spend 6 months on a feature to find out the feature is something that business or users want, nor do I want complete crap. The idea is where is the middle ground. Believe me I've dealt with many younger engineers like yourself that believe we should always roll our own solutions when its just not feasible. This is a clear distinction between a senior engineer and younger ones.
"Whats the easiest way to get something out so that we can test and measure assumptions."
I was focusing less in my comment on time-to-market and more on risk aversion to code ownership. But, to address your concern, doing things the right way up front can often cost less time and money than doing it the wrong way and working around the brokenness. This can be truth for both initial time to market as well as the more obvious long-term maintenance costs.
At the end of the day it's a calculated judgement call, and I've seen senior engineers get it wrong as well as juniors.
> You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely.
Or it performs well enough that it's not a bottleneck in profiling (and deliberate performance optimizations are unnecessary).
> The second bullet in particular can be ironic because I've seen senior-engineer-written code break production because it tried to rely on a third party library to do something without doing any unit, functional, or performance testing to ensure it was doing the right thing and doing it fast enough.
With third-party code, I'd say a true "senior engineer" has been burned enough to understand that third-party code is no different than any other code--it can have bugs, security flaws, and other risks. Third-party code gains trust the same way that first-person code gains trust: testing and time in service.
I think it's a myth that experienced engineers can write code that's more flexible and reusable. I've met plenty of experienced developers who believe they can architect a framework or library that everyone else can just build on. And they instead create big legacy software that breeds pain.
I would counter that a senior engineer is proud of his team, who knows the best practices to ship stable, working solutions. And they are not afraid to throw code away when it ages, because they have the confidence and the team to quickly build something new, that's maintainable and reliable.
My first job was working with my father, he is a very experienced automotive mechanic. Around 30 years at the time. He taught me the same idea. "If we have done our job well, you won't notice we have been there at all", the only difference is the vehicle will now function correctly. After 5 years working with dad I moved into my the field I had studied for and I've carried that advice with me over the years. So it's not just for coding.
Please share this with your interviewers. It's stupid to reject senior engineers just because they didn't implement algorithm optimization towards the end of an interview...ignoring everything else they are capable of.
Another way to look at this is that interviews are like tests where you already know what the topics are. So a company with a 'standard interview process' is testing your ability to study for and do well on a test. That's a crude measure of how well you can pick up new things and apply them, within certain bounds.
A large majority of these interviews are also testing for non-technical skills too - like communication, patience, humility, and thought process.
Don't stress out too much about interviews, they're something like 30% technical, 30% non-technical, and 40% luck.
Yes and its bollocks. I have 13 years experience on my CV. The only time I have ever needed to implement a sorting algorithm was for university exams and interviews. What's the point in studying for something irrelevant to the job? I have better things to do with my time.
Engineer as a title is largely meaningless in the software world because anyone can apply it to themselves. Once the self-proclaimed engineer hit critical mass, people who may not have otherwise done so now feel compelled to join the bandwagon lest they get looked down upon or take less pay because the well-financed companies hire engineers, not hackers or programmers.
Wow, I had never thought of the term "engineer" like that before! Suddenly my eyes are opened to the terrible abuses of language perpetrated by software phonies everywhere! Thank you for such an original and well-reasoned comment, you've caused myself (and doubtlessly, many others) to reconsider their entire professions in light of their glaring triviality in comparison to the heady and lofty work of real engineers. I'm going to go see if there's any possible way of salvaging this by importing as many npm packages as necessary to become a true engineer.
>>>The interviewers know the real problems facing the company, but the polite fiction is that they’re only temporary, and soon everyone will be able to focus entirely on the algorithms, which are what really matter. Since most companies tell the same story, candidates have to read between the lines to see if there’s a good fit.
I've walked away from a few places because of the interview process. It's like the old song the gambler by Kenny Rodgers. You need to know when to walk away and know when to run.
If I get put in a room with a puzzle sheet and they lock the door for 20 minutes, I'm out. Not because I can't solve the problems, but because any company that thinks my ONLY value is in solving puzzle questions has no idea how to hire people and have devaluated the role of the senior SE's at that company. You can tell a lot about a company by the way in which they conduct the interview process.
I just ask the interviewers how much freedom they have in the interviewing process (usually it's pretty clear) and whether they would do something different or not if they could. This kind of follows naturally from questions about non-dev responsibilities that devs have. A lot of fellow engineers at my current company believe their little quizzes actually have a lot of signal value when they really don't, I avoid working with them since they tend to have other weird beliefs. If my interviewer is giving me a whiteboard problem somewhat reluctantly because it's what he's supposed to do rather than what he'd like to do, he's probably OK to work with. The followup question is then whether I'd be working with him or not, since so many of these companies just throw you in an interview loop with whoever is available that day...
92 comments
[ 1.8 ms ] story [ 20.1 ms ] threadOne nit I'd pick with it though is that many large and bureaucratic companies won't appreciate an engineer who decides it on them to fix hiring, culture, product marketing fit and marketing. If you find yourself in this position, it's time to move on to somewhere else that will. Typically, those companies are startups.
Pressure will be created and focused onto the non-technical problem creator and reliefs for that pressure will be similarly engineered in precisely the same manner. All the while, the engineers will keep a smug, knowing look on their faces while the manager flounders around a technical terrain that they can't begin to fathom and that has suddenly become utterly hostile.
The manager will eventually 'get it', realizing that he has to work with the engineering team and not against them. Then all problems magically evaporate and a new understanding is reached.
Why wouldn't you just look for a new job? Why waste your own time on a doomed project?
I certainly hope all the engineers are in on the joke, because if I found out some others on my team conspired to create this situation without letting me decide to be involved or not I would be super pissed.
If you got handed a bunch of bullshit tasks by your senior engineer with or without a generous amount of winking and subtle sarcasm, you'd pick up on it pretty quick. You'd have all sorts of questions about why X needs to be done and would be getting no straight answers. Eventually you'd either get the picture or someone will take you aside and delicately let you in on it. Think that scene in Silicon Valley where Big Head is having his new "role" described to him, only done by the engineers rather than an HR manager.
If it looks like you need a lesson in savviness yourself, they won't let you in on it and let you flounder around just like the manager.
"We need to cut the deadline in half!"
"We can't, if we want n features we need y time"
"Can we cut it by 25%?"
The manager quit not long after, had a potentially good hardware startup that failed due to problems outside his control. Don't know what he's doing now, but I'm sure the startup life is better for him than enterprise.
In a market where there are more job openings than employable candidates, and competition for talent leads to rampant ego-stroking and title-inflation... the term "senior" has become just another word for "competent". Someone who can work independently without hand-holding.
So how do we verbally distinguish that from, "No, I really DO mean 'senior'"? Most people get 40+ working years in a career. How do you encourage humility and self-awareness, so that people don't honestly believe they've reached the 90th percentile after the only first 10% of that journey?
That depends on the company they are working for though. I have seen people (from tech and non-tech roles) tell me they are seniors/managers because they have X-years of experience.
More often then not, if someone needs to tell me they have X-years of experience rather than showing through example, I roll my eyes, and stay away.
At what age did they start? I've worked with people who were just getting started in their late 30s after a career change or kids growing up enough to become more independent, etc.
That is absolutely absurd. Plenty of tech titans and small startups have architects and senior devs in their 40's and up (I'm one, and at trade conferences I'm hardly even an outlier).
Not to mention that 90% of the industry is in the "enterprise" world (seemingly invisible to much of HN's readership), which is largely composed of devs in their 40's, 50's, and 60's. The high-octane older guys often go into consulting in their later years, where they're billing at $200-400+ an hour while giving technical direction to a team of warm bodies fresh out of school (or off the boat).
If you seriously believe that engineering is something that you do from age 25 to 35, before starting your "real career" in PowerPoint, then that's incredibly sad. Why not just go the MBA route to begin with?
And, for what it's worth, I agree: one should not be considered "senior" after 3, or 5 years. Actually, tenure matters less than perspective and problem-solving approach.
edit Also, we've all met that dev that just "gets it" and can be extremely productive regardless of time at a job/company/project. That dev also "got it" when they were pretty new to the industry.
Rookies worry too much about "job hopping". I can't count the number of people I've interviewed who had "10 years experience"... but really they just had "the same year 10 times".
2 jobs in 10 years brings an understanding of that long-term team success but a relatively small window into dev jobs as a whole.
These sentences are in direct conflict with one another.
I said that one should not be considered senior based on a time period. And then proceeded to offer two (non-time-related) characteristics I considered to be hallmarks of seniority.
On that token, Pragmatic Thinking and Learning is an awesome book for improving your problem solving approach, better understanding cognitive biases, and learning more effectively.
https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-...
The problem also comes up for the 3-5 year mark when pay is involved. At my current company, it was impossible to make a certain salary without being promoted to Senior. The bigger problem was that the company has a slightly unrealistic view of the market, and to get any decent talent you'd have to be in the Senior pay bracket.
Ultimately I think the best solution is to screen appropriately and decouple salary from title. I think the best model would be to never hire anyone as a Senior, but let the Seniors emerge.
I also feel that this model of hiring is emphasized by the craze over agile (and particular SAFE) where all the engineers are supposed to be like lemmings that take orders from product owners. If you get the right team I suppose this is possible to do, but the lack of senior leadership on a team (and it's deferral to non-technical people like scrum masters and product owners) leads to unnecessary bikering among engineers on the 'right' way to solve a problem.
But you're right, there is no perfect system.
As far as I can tell, the company I'm at follows the model alexbanks described, and it seems to work quite well. We generally do not hire people on in senior or lead roles. If someone has 15 years of experience and they're a team lead at their previous job, the chances are still very high they'll have to start as a "normal" developer with us. (Notably, we do not tie salary to title. A "software developer" can have an arbitrarily high salary if needed.) If they demonstrate the capacity for leadership, we will identify that and very quickly offer them more responsibility and promotions whenever the opportunity arises.
Really it seems like we just need more granularity than "senior" or "not senior."
That's my perspective at 3 years into startup software engineering.
This was the point of the original article.
Now that we have technical career paths where one can expect to continue as technical individual contributor, the official "Senior Engineer" title falls roughly in the middle (slightly on the lower side) of the career ladder[1]. I'm generally OK with this personally, so long as we distinguish between the title "Senior Engineer" and the role "senior engineer". The role I would equate to Randall Koutnik's "Finders"[2].
[0]I talked about this in a little more detail on another thread: https://news.ycombinator.com/item?id=11545294
[1]http://changelog.ca/log/2013/08/09/software_engineer_title_l...
[2]https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...
oh right, the OFFICIAL one. Sure.
> falls roughly in the middle (slightly on the lower side) of the career ladder[1].
Not really, as the upper levels aren't reached by most people.
Not official in the sense of "there is some standards committee making these designations", but it seems to be a commonly accepted practice that the title of "Senior Engineer" is assigned to someone who "is capable of being given a high level (and often vague) task, and work completely independently on it and finish it" but not anything more.
But my main concern was distinguishing between the title and the role. When I think of the role, I think we generally consider someone to be senior when they can:
a) work through very thorny technical problems and find novel solutions
b) connect technical solutions to the needs of the business
c) provide leadership or mentoring to other engineers
Like or not (I don't, personally) the title and the role use the same words but mean different things.
> Not really, as the upper levels aren't reached by most people.
I'm not clear on what your point is. Is it in the middle of most people's career? No. Is it in the middle of most technical career ladders (as used in various tech companies)? Yes.
My point is that in places where there is a technical career ladder, there are titles that do actually reflect (what I consider to be) the role of a senior engineer. This is how tech companies get around the fact that convention has lowered the expectations of the title Senior Engineer.
The core problem is that there is confusion about the relationship between title and role. The OP is trying to fix this confusion by raising the standards of the title to match the role (by explaining what the role really entails). I'm just trying to clarify the conventions set by the industry so that people can plan their careers accordingly.
Why would senior by the 90th percentile?
Much in the same way that somebody founding a startup can be "engineer" or "CTO" or "Software king Ninja Level 7 dan grandmaster." Titles will never be objectively consistent, this is why the whole industry is now discussing consistent interviews instead hiring based on titles on resumes.
A junior engineer is proud he got his code to work, an experienced engineer is proud of the code he wrote to get the feature to work, and a senior engineer is proud of the code he didn't have to write to get it to work.
Some fallacies I've seen from senior engineers:
"Let's ship the simpler solution even though it has clear problems. We'll hide it behind a feature flag and deploy it to a few machines first to make sure nothing disastrous happens."
"Let's coerce a third party library to do the thing we want even though it wasn't really designed to do what we want. By using the third party library we don't have to take ownership of what we are writing! So much less code to maintain!"
The second bullet in particular can be ironic because I've seen senior-engineer-written code break production because it tried to rely on a third party library to do something without doing any unit, functional, or performance testing to ensure it was doing the right thing and doing it fast enough.
After having been in the software engineer for close to a decade, I see an increasingly worrying trend where companies just assume their engineers are incompetent and favor delegation to third party libraries, external services, and devops/metrics/monitoring to solve all problems. As someone who considers himself a competent engineer, I find the trend saddening because I'm not trusted to write correct code either.
1. "Let's ship the simpler solution even though it has clear problems." You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely. Shipping the simpler solution is a way to test the waters and make sure you're building what is expected or wanted.
2. "Let's coerce a third party library to do the thing we want even though it wasn't really designed" Same point as #1. Whats the easiest way to get something out so that we can test and measure assumptions.
Overall if you've read the article its about reducing risk. I don't want my team to spend 6 months on a feature to find out the feature is something that business or users want, nor do I want complete crap. The idea is where is the middle ground. Believe me I've dealt with many younger engineers like yourself that believe we should always roll our own solutions when its just not feasible. This is a clear distinction between a senior engineer and younger ones.
I was focusing less in my comment on time-to-market and more on risk aversion to code ownership. But, to address your concern, doing things the right way up front can often cost less time and money than doing it the wrong way and working around the brokenness. This can be truth for both initial time to market as well as the more obvious long-term maintenance costs.
At the end of the day it's a calculated judgement call, and I've seen senior engineers get it wrong as well as juniors.
Or it performs well enough that it's not a bottleneck in profiling (and deliberate performance optimizations are unnecessary).
Seems like they were "senior" only in title.
I would counter that a senior engineer is proud of his team, who knows the best practices to ship stable, working solutions. And they are not afraid to throw code away when it ages, because they have the confidence and the team to quickly build something new, that's maintainable and reliable.
A large majority of these interviews are also testing for non-technical skills too - like communication, patience, humility, and thought process.
Don't stress out too much about interviews, they're something like 30% technical, 30% non-technical, and 40% luck.
It seems OP is mocking this mindset.
I've walked away from a few places because of the interview process. It's like the old song the gambler by Kenny Rodgers. You need to know when to walk away and know when to run.
If I get put in a room with a puzzle sheet and they lock the door for 20 minutes, I'm out. Not because I can't solve the problems, but because any company that thinks my ONLY value is in solving puzzle questions has no idea how to hire people and have devaluated the role of the senior SE's at that company. You can tell a lot about a company by the way in which they conduct the interview process.