R and D — not: R or D

A few days ago a frustrated recruiter from an agency we have been using on and off for a while wrote to me

I [come] to the conclusion that your standards are impossibly high.  I don’t see myself being able to fill any of your roles.

For a fact, we do hire engineers on an on-going basis via all conceivable channels including agencies, which goes to show that it isn’t impossible if difficult.  We do pride ourselves for hiring only the top candidates, but, hey, that’s what they all say, right? Anyways, this little episode made me think some more about our hiring process and in the next couple of posts I’d like to shed some light on how to find great talent. Let’s first take a look at the target candidates.

The candidates we are looking for

A number of folks (most notably Joel Spolsky) have written extensively on this subject in the past and boiled it down to the simple and catchy formula: “smart people who get stuff done!”. In a software industry context I actually prefer to call them “people who can do both research and development”. Unlike a number of other places out there, here at Greenplum we’re looking for people who can drive a research agenda, solve hard problems, and communicate the solutions effectively, and, at the same time, they have to be able to turn theoretical results into enterprise software. Simple enough you might think, and yet, I see plenty of candidates who tell me they do R&D but “don’t code”. I’ve come to the conclusion, most candidates are good at one or the other — but only very few excel at both. In order to find the right talent (and enable a larger team to do so in order to scale out the process) you need to understand your candidate pool. The little drawing on the left is what I found captures the landscape best: the theoreticians, the pragmatists, and, well, the people who are both and these are the ones you want to hire.

The theoreticians. The upper left quadrant (‘research’) are the theoreticians who may very well be able to solve hard problems but are having a hard time to turn their results into robust and elegant software solutions. In fact, writing good software is, as you know, extremely challenging. Turning the solution for a hard problem into software is much harder than most people think. Turning it into maintainable software that leaves enough headroom to use it as a workbench for future research is even harder. (If you don’t believe me, try to find an implementation of Paxos that doesn’t require major rewrites before it fits your project.)

The pragmatics. The lower right quadrant (‘development’) are the pragmatics who produce huge amounts of code rapidly that, to no surprise, needs constant fixing afterward. The pragmatics use the generally agreed upon fact that there is no such thing as perfect software as an excuse to create prototypes that tend to escape into production.

Ironically, both of these group have surprisingly little regard for each other: the pragmatics call the theorists “too academic”, the theorist think of the pragmatics as “hackers”; and that’s putting it mildly. Interestingly, it also does not occur to them that combining their skills/talents would be highly desirable — they typically view the world as either research or development.

R&D: pragmatic theoreticians

Here at Greenplum, we’re looking for people who can do it all — the candidates in the upper right quadrant (‘R&D’). And that’s not just because we think it’s “somehow” better. What we’re looking for are folks who are strong abstract thinkers, who can solve hard problems on paper, file for patents, and publish their solutions; but also design and build elegant software solutions, drive designs top-down and implementations bottom-up.

Luckily there are folks who are willing to take on hard challenges! If you’re intrigued and think you have what it takes, visit http://www.greenplum.com/about-us/careers and apply for the Query Processing or the Distributed Systems Engineering position.

P.S. we’re opening offices in Beijing and Seattle!

Advertisement
This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to R and D — not: R or D

  1. Pingback: got phd? « theory in practice

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s