Types of Software Engineers (Part 1)
You can't hire solely rock stars and hiring the wrong person is worse than leaving the position vacant, but what makes someone right? In the first of a series of posts on building and manging teams, I'd like to talk about the types of software engineering positions. Who you should hire depends on your exact needs.
It is odd to me that positions are headlined by seniority, (Junior|Intermediate|Senior|Principal) Software Engineer. I've found the right fit to be far more important than how long someone's been at it. You may have an upper limit on how much you can afford to for a role, but you shouldn't let that define who you advertise/look for.
In this post I'm going to quickly run through some of the major categories of engineer/position types. As with anything no one person or position will fit snugly in to a single category, but I've found it helpful to think in these terms.
Heads Down Coder
Do you have some serious low-level bit banging that you need to get done? The problem well defined and isolated? Once it's done it'll be done and you won't for the most part need to touch it again. Then you need a heads-down coder. This is the best person to write some code to talk over a serial port to a stepper motor controller or to go off and implement a new UI widget to spec. Have a big data computation problem with Hadoop ready to throw at it, hire this type of person to crank out the map reduce job.
Heads Down Coders want stability and structure. They want to know what they're supposed to be doing for the next 3 weeks and they want to be left alone to go and do it. Generally meeting averse and one of the best candidates for remote employees. HDC's can be hard to evaluate as they're generally not outgoing, excitable, or great communicators. They are prone to think before coding.
While many/most "real" software engineers look down on Search-n-Paster, there's definitely a time and place for them and trying to fill this type of position with the wrong person is a recipe for unhappiness. SPC's are defined by their lack of deep knowledge or understanding of programming, much less computer science. The just search until they find something that does what they need and then copy-n-paste it in.
They're the right people to task with things like building out Wordpress sites for clients where the closest they'll come to writing code is searching google for who to make X plugin cooperate with Y or finding a snippet of code that makes a call to the Twitter api and iterates over and displays the results. If they can't find something similar to what's needed they'll quickly get stuck, but in the right situation that won't happen often and they'll get things done.
This is the type of engineer you want designing your API and serving as director/caretaker of your overall architecture and technical direction. These positions are often labeled Architect, but the title implies ultimate seniority, which isn't always needed. It is true that it requires working on a variety of projects to have a broad enough scope and enough experience to be able to quickly judge the merit of options.
A Big Picture engineer will have a varied resume with lots of languages, frameworks, and even areas of focus. Beware of the candidate who's spend the last 7 years using X. She'll know it inside and out, but won't have a clue if it's the best option to build Y upon. In this type of role you need to have done a bit of everything. UI, client, server, signal processing, operations, etc. You don't have to be an expert in any one of them, that's for the Heads Down Coders, but you need to be able to carry on deeply technical conversation with anyone on the team about whatever it is they're working on.
We'll pick this series up next week with Part 2, where we'll cover a few more types and set things up for a discussion of finding the right people.