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,
(JuniorSenior|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
Part two can be found