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”:
- The Ability to Deliver Bug-Free Code Quickly and Consistently
- The Inability to Be Bullshitted
- The Ability to Explain “Why”
- Complete Technology Agnosticism
- 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.