Senior Dev capabilities

Understand the in and outs of the language (not just frameworks);
Understand everything about the framework they use and this includes:
- Development and release process;
- Known bugs;
- They should have, at least once, made a PR with a bug fix to that repo;
- Awareness and basic understanding of competitors;
Understand everything about the build & release process of their application;
Understand how a backend REST api works;
Depending on the application, they should be able to design a CI/CD pipeline
Solid understanding of OOP principles;
Solid understanding of Functional principles;
Solid understanding of unit and integration testing (coverage >= 80%);
Databases understanding, at least understand how an ORM works and know the most common DB concerns
Doing code review and writing code every day.

Skills

Deliver – Things actually get finished, and to spec – often exceeding the spec to cover scenarios the spec writer hadn’t considered.
Bug-Free – QA and customers have a very tough time finding bugs in their code. When they do, it’s usually minor and a painless and/or quick fix.
Quickly
- This is perception based, but generally technical and non-technical staff agreed it was “Quickly done”.
Consistently
- Management considered the pace of delivery predictable, which is not the same as “the same”. Management could develop a good sense of when to expect work depending on the phase of the project, volume of meetings, quality of specs, etc.

“Bullshit” comes in many flavors on a software development project:
- Laughably incomplete, inconsistent, and/or non-existent specifications
- Hilariously unrealistic deadlines
- Tragically incompetent co-workers

A junior engineer cannot explain why they are doing what they are doing in the way they are doing it.
A mid-level engineer has justification for some of their actions/approaches but not all.
A senior engineer knows exactly why they are doing everything they do, and can explain the rationale of their choices in exhaustive detail
makes them good coaches and mentors to other members of the team.

understand the technology of today is not the technology of tomorrow, and that “hot” technology never stays hot
sophisticated method of evaluating new and old technologies that examines the technology from a wide array of angles
- What problems does the technology solve better than other solutions?
- Where did the technology come from?
- What is the switch cost to, and away from, the technology assuming it is adopted?
- How ready is the organization to adopt this technology?
- What is the learning curve for this technology?
- How readily can we find staff who know this technology?
- Is there commercial support for this technology?
- What is the anticipated life-span of this technology?
lead them to reject “hot” technologies in favor of ones that are tried-and-true.
to push for unproven technologies because of how well they solve a particular problem
there is a methodology of this evaluation, not simply a desire to learn or not learn something new.

As long as time and money are constraints for a project, work estimates will be required during the planning progress
extremely difficult
accuracy is not the goal of the estimate, so much as predictable margins of error.
if you are within 30% of your estimate you are doing a good job estimating.
senior engineer views estimates as a difficult challenge to be surmounted, and as a result will normally ask for dedicated time simply to come up with the estimates.
will not give an off-the-cuff estimate even if their job is on the line, as they understand the dire consequences of a “guesstimate”