An Attempt at a Pragmatic Framework for Defining a “Senior Engineer”

Brandon Hays’ article “The Conjoined Triangles of Senior-Level Development” made me reflect on all of the Senior Engineers I’ve worked with.  If I were to guess, these would be the shared traits that lead others to declaring them “Senior Engineers”:

  1. The Ability to Deliver Bug-Free Code Quickly and Consistently
  2. The Inability to Be Bullshitted
  3. The Ability to Explain “Why”
  4. Complete Technology Agnosticism
  5. A Process to Estimate Work

The Ability to Deliver Bug-Free Code Quickly and Consistently

Breaking down this trait:

  • 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.

Excellence at writing and delivering software is an immutable requirement of a senior engineer. If you can’t do this consistently you may be a valuable contributor to your team, but most people would not consider you “senior” in my experience.

The Inability to Be Bullshitted

“Bullshit” is what defines most software projects. If your first reaction is “That’s not true” then I would wager that you do not have a long history of working on software projects. “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

My use of “Laughable”, “Hilariously” and “Tragically” is deliberate. Senior engineers, in a project planning meeting will most likely involuntarily chuckle or let out a long exasperated sigh when “the plan” is presented, which tends to make them quite unpopular with those who came up with “the plan” – unless the senior engineer has already won their respect. In many cases, that sigh or chuckle could indicate that they are about to save the project a lot of pain, time, or money, provided they are asked to explain the reason for their reaction.

The Ability to Explain “Why”

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. The ability to explain “Why” is the characteristic that makes them good coaches and mentors to other members of the team.

Complete Technology Agnosticism

Senior engineers understand the technology of today is not the technology of tomorrow, and that “hot” technology never stays hot. They have a sophisticated method of evaluating new and old technologies that examines the technology from a wide array of angles, including:

  • 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?

A senior engineer’s ability to evaluate technology will often lead them to reject “hot” technologies in favor of ones that are tried-and-true. It will also lead them to push for unproven technologies because of how well they solve a particular problem. The key is that there is a methodology of this evaluation, not simply a desire to learn or not learn something new.

A Process to Estimate Work

As long as time and money are constraints for a project, work estimates will be required during the planning progress. Estimating software development is extremely difficult. An “Accurate Estimate” is an oxymoron, so accuracy is not the goal of the estimate, so much as predictable margins of error. In my experience, if you are within 30% of your estimate you are doing a good job estimating. Inexperienced project/program managers will balk at the thought of an estimate being 30% over or 30% under, but experienced project/program managers will know that badly estimated projects can easily go 300% over.

It is beyond the scope of this post to describe everything that goes into making a good estimate, but suffice to say a 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. They 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” when the jobs of their peers and/or the company’s future is on the line.

Interviewing a Candidate for a Senior Engineer Position

If you wish to attempt to hire a Senior Engineer, here is what I would recommend as a loose framework for interviewing them:

Trait #1 (The Ability to Deliver Bug-Free Code Quickly and Consistently) can only be evaluated via a take-home coding test that asks them to write a non-trivial system. Attempting to do it in the office has the dual disadvantage of adding undue stress to the candidates coding effort, as well as not allowing for adequate time for the engineer to finish the system. The system should  need to be modeled, with the opportunity to utilize multiple programming paradigms. An example might be writing a data exchange system for a financial company on one side, and a trucking company on the other. This will expose their skills in problem decomposition, provide a host of opportunities for a wide variety of programming techniques, and offer lots of edge cases for bugs to hide.

Traits #2 – #5 can all be assessed with open-ended “What would you do?” scenario based questions such as:

  • “Your product manager calls a meeting to review specs that were emailed to the team the day before. What types of questions would you ask in the meeting?”
  • “Frameworks such as _________ have (risen|fallen) in popularity. Why do you think that is?”
  • “Do you have a favorite programming language/framework? If so, why are they your favorite?”
  • “If I asked you to build a complex extension to a large mission-critical legacy software system, how would you go about providing estimates?”

Bear in mind the one caveat, as all of the points made is “in my opinion”. Your mileage may vary.

6 thoughts on “An Attempt at a Pragmatic Framework for Defining a “Senior Engineer”

  1. Fantastic write-up of the topic, thank you! I also liked Brandon’s article, but yours is more thorough. Is there a chance that you will write an article about how to make good work estimates?

    • I’m glad you liked it! I’m going to think about how to summarize making good estimates such that it fits in a blog format. Currently I’ve got enough thoughts on the matter to fill a book.

    • Here’s what I’ve come up with – let me know if you’d like to see it as a full blog post:

      1. Never Be Bullied into an Estimate
      2. Get Approval for Time to Estimate
      3. Be Able to Recite the Requirements from Memory
      4. Be Intimately Familiar with the Entire Codebase
      5. Diagram the Work to Be Done in Exhaustive Detail
      6. Painstakingly Break Down Every Development Task
      7. Know Which Tasks Will Go to Each Team Member
      8. Know the Quality of Existing Tests and Their Test Coverage
      9. Know What Each Member of Your Team Is Realistically Capable Of
      10. Put “Uninterruptible Coding Days” on the Schedule
      11. Gauge Burnout Potential and Consequence
      12. Establish Backup Engineers
      13. Know the Acceptance Tester’s Capacity
      14. Know the Deployment Windows and Required Lead-Times
      15. Know Everyone’s Vacation Schedule
      16. Estimate Required Refactorings Separately
      17. Present Your Estimate Like You Are Bidding for Work

  2. “if you’d like to see it as a full blog post” – Of course 🙂 Looking at your list, you could easily write not one but a *series* of blog posts about this.

    I recently changed jobs and I don’t have enough information yet about the code and the team to make good estimations. Moreover, management requires us developers to make estimates on the spot. We are not given time to analyze the task before estimation. This leads to bad estimations, which leads to losing face, and makes this even harder next time. It’s like a downward spiral.

  3. I’m sorry you have had to go through that. I’ve been there and know how that feels.

    I am not sure it will help you feel better (it may actually make you feel worse), but I expand my points into a full blog article:

    I did not do a series simply based on time, but if there are particular points you’d like me to expand on let me know.

Add your thoughts