Ask HN: What do you expect from a senior software engineer?
9 comments
What distinguishes senior practitioners from juniors, in software development and in other crafts, is the number of errors they've already made and the lessons they learned from those errors.
Those mistakes and learnings together inform their judgement when approaching tasks and allow them to ask questions like:
* Is this code robust enough? (They ask because of the many times they pushed code and suddenly everything broke.)
* Should we even be building this? (They ask because of that one time they didn't ask, and wasted weeks of effort on something that was never used.)
* Is approach A the best way to achieve our goal? (They ask because of that one time they tried A, thought it would take one week, but spent two months on it instead.)
* What happens when we're asked to add X feature? (They ask because of that one time they were surprised by a feature request and had to rewrite a bunch of their code.)
Those mistakes and learnings together inform their judgement when approaching tasks and allow them to ask questions like:
* Is this code robust enough? (They ask because of the many times they pushed code and suddenly everything broke.)
* Should we even be building this? (They ask because of that one time they didn't ask, and wasted weeks of effort on something that was never used.)
* Is approach A the best way to achieve our goal? (They ask because of that one time they tried A, thought it would take one week, but spent two months on it instead.)
* What happens when we're asked to add X feature? (They ask because of that one time they were surprised by a feature request and had to rewrite a bunch of their code.)
Wrote a whole post about that:
http://www.mooreds.com/wordpress/archives/2812
Short answer is it is different for each job. I would ask for rubrics from interesting companies (interesting to you) rather than hn at large.
http://www.mooreds.com/wordpress/archives/2812
Short answer is it is different for each job. I would ask for rubrics from interesting companies (interesting to you) rather than hn at large.
Something that I have been working on for my own use, but can be helpful to you:
https://littleblah.com/post/2019-09-01-senior-engineer-check...
https://littleblah.com/post/2019-09-01-senior-engineer-check...
A senior software developer can be given a vague contradictory notion of a a whole application (or part of one) and turn it into a scalable, performant, cost-effective beautiful product using the best set of tools and technologies to fit the job. They will deliver exactly what you had in mind within the estimated range provided before they even started.
In addition, they will do it while abstracting away all of the pain and complexity as part of that process, communicating only to provide accurate updates on progress and asking thoughtful probing questions. They make all of their work seem effortless in the process.
In addition, they will do it while abstracting away all of the pain and complexity as part of that process, communicating only to provide accurate updates on progress and asking thoughtful probing questions. They make all of their work seem effortless in the process.
That's a lot to ask of someone. If that is senior, what is a principal engineer? That's a whole different level in our vaguely defined informal software engineering world.
We have a rough scope and impact for each level on our Standard at http://levels.fyi/standard
I like these standard definitions, thanks for sharing.
In one word, leadership. A senior anything is someone with enough experience to be able to lead a development effort.
They should have a proper understanding of what it takes to build a reliable and robust system end to end.
"How quickly" is the wrong question. It's not about speed of delivery, but quality. A senior engineer would know that and if someone asks them to build something quick, they should be honest about the loss in quality and technical debt that will be incurred due to speed of delivery.
They should have a proper understanding of what it takes to build a reliable and robust system end to end.
"How quickly" is the wrong question. It's not about speed of delivery, but quality. A senior engineer would know that and if someone asks them to build something quick, they should be honest about the loss in quality and technical debt that will be incurred due to speed of delivery.
Seniors should have demonstrated experience designing systems and libraries that then became reality.
That might sound obvious, but people can end up with senior titles on their resume just by hanging around places doing nothing but maintenance and small additions for long enough, and barely accruing any design chops.
That might sound obvious, but people can end up with senior titles on their resume just by hanging around places doing nothing but maintenance and small additions for long enough, and barely accruing any design chops.
There's another comment that makes the same observation about the senior title on the resume. It's almost like the first thing you have to figure out when talking to a senior engineer is: title or talent? (I know talent might not be the best word, but it sounded neat. I also think talent doesn't refer to an inherent ability to do something but a set of skills developed over time to a high degree of efficiency)
That they keep a process which lets their team deliver new features without breaking existing features. I can't think of anything else, most things are so context dependent but that one is fairly universal.
I think that also highlights that they should care about the big picture enough to even worry about breaking existing things - that and be able to see the big picture at all.
I expect such a 'senior software engineer' to be extremely competent with some of the best practices in the industry and to have a very strong portfolio of experience that is worthy of the role.
Some of the typical expectations of what I regard as 'senior' are usually as follows.
Technical Skills:
* A polyglot at many programming languages and has no trouble at learning new ones to a proficient level if required.
* Has useful open-source projects and significant open-source contributions in widely used projects. (Bonus for commit-access) No silly hello-world/test-123/git-push-demo repositories.
* Competent at data-structures and algorithms and must be able to write a proof to help explain some of the time/space complexities of these concepts.
* An understanding of the appropriate tool/library for the scenario, dismisses programmer zealotry and can compare and reason about choosing one tool over another.
* Writes clean documentation, tests (or delegates them to SDETs) and uses continuous integration for changes in the code.
* Expert-level on at least one version-control software, Git/SVN or TFS and conducts code-reviews on patches either in open-source or company-level contributions.
* Knowledge of a development methodology to use for software development and delivery to meet the user/client requirements.
Soft skills:
* Participates or leads in the interviewing process and justifies the questions they ask with the projects that they work on.
(It is really no good, throwing a leet-code problem and then the candidate asks if you use it and you will look rather silly as an interviewer if you don't.)
* Gives both technical and non-technical presentations at conferences or meetings about difficult engineering problems or the like.
* Can communicate towards many teams and or different audiences eloquently and understands different perspectives of the user. Not just engineering teams.
* Mentors junior programmers to adopt the best practices enforced in the company to become better programmers.
In this industry we have self-proclaimed 'senior' engineers that don't know what a AVL-Tree is, can't implement a LRU cache or cannot talk to a non-technical audience about what they do. If these 'engineers' contributed to a large compiler project, then all of these requirements would have been met. Unfortunately in 2019, the title of being 'senior' can be given to literally anyone (even with less than 2 years of experience) in their own organization but elsewhere, they are equivalent to a entry-level coder with a heavily decorated CV.
They may look 'good' on paper, but I think that is not enough to truly find out if they are senior-level. So my approach is more or less of a senior-software-engineering CAPTCHA test.
Some of the typical expectations of what I regard as 'senior' are usually as follows.
Technical Skills:
* A polyglot at many programming languages and has no trouble at learning new ones to a proficient level if required.
* Has useful open-source projects and significant open-source contributions in widely used projects. (Bonus for commit-access) No silly hello-world/test-123/git-push-demo repositories.
* Competent at data-structures and algorithms and must be able to write a proof to help explain some of the time/space complexities of these concepts.
* An understanding of the appropriate tool/library for the scenario, dismisses programmer zealotry and can compare and reason about choosing one tool over another.
* Writes clean documentation, tests (or delegates them to SDETs) and uses continuous integration for changes in the code.
* Expert-level on at least one version-control software, Git/SVN or TFS and conducts code-reviews on patches either in open-source or company-level contributions.
* Knowledge of a development methodology to use for software development and delivery to meet the user/client requirements.
Soft skills:
* Participates or leads in the interviewing process and justifies the questions they ask with the projects that they work on.
(It is really no good, throwing a leet-code problem and then the candidate asks if you use it and you will look rather silly as an interviewer if you don't.)
* Gives both technical and non-technical presentations at conferences or meetings about difficult engineering problems or the like.
* Can communicate towards many teams and or different audiences eloquently and understands different perspectives of the user. Not just engineering teams.
* Mentors junior programmers to adopt the best practices enforced in the company to become better programmers.
In this industry we have self-proclaimed 'senior' engineers that don't know what a AVL-Tree is, can't implement a LRU cache or cannot talk to a non-technical audience about what they do. If these 'engineers' contributed to a large compiler project, then all of these requirements would have been met. Unfortunately in 2019, the title of being 'senior' can be given to literally anyone (even with less than 2 years of experience) in their own organization but elsewhere, they are equivalent to a entry-level coder with a heavily decorated CV.
They may look 'good' on paper, but I think that is not enough to truly find out if they are senior-level. So my approach is more or less of a senior-software-engineering CAPTCHA test.
"Unfortunately in 2019, the title of being 'senior' can be given to literally anyone (even with less than 2 years of experience) in their own organization but elsewhere, they are equivalent to a entry-level coder with a heavily decorated CV."
This situation is one of the reasons I asked the question. The title is being overused imo - and assigned by management to developers instead of by peers or an actual technical benchmark.
"So my approach is more or less of a senior-software-engineering CAPTCHA test."
I love this quote, and will use it from now on :D
Personally I think the industry as a whole is fairly bad at judging a developer's skill level at anything past a junior level when it comes to hiring.
This situation is one of the reasons I asked the question. The title is being overused imo - and assigned by management to developers instead of by peers or an actual technical benchmark.
"So my approach is more or less of a senior-software-engineering CAPTCHA test."
I love this quote, and will use it from now on :D
Personally I think the industry as a whole is fairly bad at judging a developer's skill level at anything past a junior level when it comes to hiring.
Correct, this is why we still test senior developers with algo interviews. The reality is no one knows what the hell a senior developer is.
The tone of this post is rather negative, but I think you make a lot of good points.
What are you expectations?
What skills or concepts should they have mastered?
How quickly should they be able to deliver features or products?
By nature the question is a little amorphous, but I think it beneficial for mid-career developers to understand the expectations of experienced developers, and hiring managers, with regards to senior level positions and work.