For HR and legal purposes, most development companies classify Software Engineers into ranks from I to IV (or V). The higher the rank, the higher the responsibilities, expectations, independence and pay grade. To cut it as an interviewer and manager, you’ll need to classify people accurately with a minimum amount of direct personal exposure: a non-ideal but practical requirement of most hiring processes.
While we don’t regularly use titles at OpenRain, we nevertheless have to distinguish senior talent. The core issue is, “How do you objectively identify ‘senior’ engineering qualities?” Today we’ll focus on several key factors always present in quality engineers, independant of language and platform.
Instinct
He/She has developed extraordinary technical relevance filtering to the point of being able to scroll through a never-before-seen 500 line file in a language they don’t know, and tell you..
- how complicated the code is.
- where potential bugs are.
Even with no formal knowledge of code smells or design patterns, a senior developer can sense ugly code and architecture from a mile away even if they don’t yet know exactly why.
Foresight
Long-term implications are always on the mind of the Senior Software Engineer. They’ve been through the end-to-end development process (from requirements gathering to product maintenance and end-of-life) numerous times, know what issues are going to arise and will point out a suitable solution long before the symptoms start to appear. (This quality thus becomes most apparent after delivery when work is bombarded with never-before-seen use cases.) The truly elite developer is often hard to identify because they’re solving the important issues before anyone else notices the problem. (Ben is a primary example of this extraordinary perceptiveness.)
Results Focus
Knowledge without application leads to arrogance without insight. Senior developers are always focused on results which stand the test of time and can easily see through posers who fluff their way through status meetings.
Communication
New developers seldom understand the required differences of communication between different types of stakeholders. Newbies tend to treat all stakeholders as authoritative figures, and are quick to lose direction when exposed to people with differing incentives. The criticality of non-verbal developer communication is also apparent to the senior engineer. For example, a green engineer may see issue tracking as micro-management, automated testing as an ideological obsession, and project planning as administrative overhead, but these are all monumentally important aspects required to keep all developers and stakeholders in a real-time communications loop, since many do not directly interact. A senior engineer will see these concepts as empowering and often get grouchy when not present, because not having clear priorities and documentation introduces roadblocks to results.
Time & Priority Management
A senior engineer can more-or-less tell you what their schedule looks like a week out, even if it’s not written down, and won’t be hesitant to express any issues with workload ahead of time.
Estimation
New software engineers seem to invariably produce time estimates magnitudes off from reasonable numbers. The issue largely appears to be one of Foresight since accurate estimates are oft best produced by benchmarking current requirements against past similar project experiences: a task more easily accomplished with experience. This issue is an arguing point against the “Customer is Always Available” aspect of eXtreme Programming since a green developer is generally more likely to over-commit to a workload than a senior.
16 replies on “Identifying Senior Software Engineers: Six Critical Differences”
echo “I still have to run OpenRain, but when I find time to breath,” | sed -e “s/breath/breathe/”
Thanks 🙂 Fixed!
Hello Dzone and Reddit!
Pretty good list, but I think your last point is a bit of a stretch. Resource estimation is hard and you never know you got it right until the project is complete (or canceled).
When you are looking to hire, it is hard to evaluate someone’s estimation skill in an interview.
This brings up the related question, once I have identified these six points as valuable for hiring, how can we effectively evaluate developers in this context?
@dennis: You can evaluate a developer WRT to his estimation capabilities (point #6) e.g. like this…
Give him the draft specs or requirements of a project or product feature you completed and ask him to do an estimation. (Note: It is more useful, if the specs or requirements here, are rather coarse grained and the overall project not too huge.)
Then compare his numbers to your record.
More interesting than his accuracy, is his overall approach… more or less wild guesses or rather breaking things down into reasonable and easier to guess pieces?!
Maybe, that person is even able to ask questions useful to do a better job or taking into account things holding even more potential …
Cheers!
(Comment have apparently been broken for some users. Sorry about that!)
@dennis, @Jöerg
A technique I generally use is as Jöerg suggests. Take a very, very basic set of requirements, and watch the candidate think out loud. There is no “right” response in the absolute sense. The important part is that they state assumptions, potential issues etc., and come up with reasonable numbers that are in line with past experiences and establish a mental process and order to the given tasks. A simple statement of “4 weeks” is fishy … no set of use cases, requirements etc. I’ve seen has ever been so clear as to flat-out respond with an exacty number without some exploratory dialog.
@Jöerg
To more directly answer your question..
Quantification of these qualities is extremely difficult, because assessment is subjective and highly dependent on the perception of the interviewer. I can’t give a recruitment company my standard developer interview question list and expect to get back the same answers because the recruiter is probably much less tech savvy and unlikely to pick up on warning signs.
Recruiters and HR departments want web-based, automated multiple-choice assessments which fit people into convenient little boxes… but that’s just not how life works. “It takes one to know one”, so-to-speak.
My ideal assessment process is to hold an initial phone call with a good engineer, and follow up in office with a team of two or three people who individually contribute overall impressions and determine a final yes/no recommendation; the goal being a compromise between traditional HR-heavy recruitment and the glacially slow communal process of someplace like Google.
I’m still not sold. I agree when interviewing the discussion and thought process is always more interesting than “the answer”. But often during a tense interview its hard to get the candidate to talk as they are afraid to say something stupid (imagine…)
So while discussing the solution strategy for any project we would expect that it would lead, implicitly, to a discussion of the overall project scale. In any case this should limit the estimation range to something believable.
However, don’t think I would reject (what otherwise appeared to be) a good candidate because I felt his estimation was in left field.
Estimation is often dependent on the development organization where some groups like to estimation high (just to be safe) and some like to estimation closer to the bone (I call this “name that tune” estimation).
Besides, what if someone gives me an estimate two or three times lower than the project was complete in and is capable of doing it…
cheers,
d.
@dennis
I agree with your observations. Different companies are going to want to see different approaches to the task. Determining if the candidate is a good match is so cultural and subjective that this makes technical assessment by non-technical HR or recruiter look obscene.
I also would not outright reject a candidate due to wonky estimates, but for classification purposes it’s still a valuable piece of information to weigh against other factors.
[…] Identifying Senior Software Engineers: Six Critical Differences Posted by Federico Filed in Agile Development, Programming […]
That’s a good list, and definitely points to me as being on the ‘newbie’ end of the scale. It’s nice to see what I need to work on in print, too. Some just need time (estimates… I so suck at estimates!) and experience, but others are about getting your head straight.
This is a short nice list. But I think working with people as a senior engineer has many more aspects. The senior engineer is not only the one with the best technical abilities but also the one who realizes he works with people more than he works with computers. I would call a senior the “go to” guy for advice. If less senior engineers want to ask him question, find it useful and are not afraid of rejection then you truly found a senior. Of course all depends on your environment. In a startup the focus might be on delivering fast and forget about educating youngsters but this is a good policy only if you have lots of seniors on the team. Otherwise and in bigger companies the teaching abilities of a senior engineer are more important sometimes than his coding abilities.
On a related tangent I wrote a post a while ago: 36 steps to success as technical lead
Cheers
This article is certainly not an all-inclusive list; I don’t think it’d be possible to encapsulate every ideal quality. Awesome technical abilities aside, you’ve highlighted a great point that senior engineers know how to behave when away from the keyboard and know the correct communications medium and style for the given context.
Agree with the list. I could add few more. Unfortuately many interviewers are incapabale of coming up with appropriate set of questions to test this kind of high level skill sets. Often, the interview degenerates to a laundry list nuts and bolt level technical questions.
@Pranab
Agreed. When HR or recruitment departments automate candidate handling process, there seems to be tendency to focus largely on technical factoid minutiae which in the grand scheme of business probably aren’t the most important things to be evaluating. It’s just easier, so I’m sure the world will continue to scrape resumes for keywords for years to come.
[…] via Identifying Senior Software Engineers: Six Critical Differences | Preston Lee. […]