What do I look for when hiring an engineer?

I’m don’t spend much time on Quora, but I was reading a different thread and I came across the question: What Makes a Software Engineer Good? Now anyone who has worked with me can tell you that I am pretty opinionated about this subject. So since there wasn’t already someone saying what I would have, I decided to post an answer. Here is that answer:

I’ve interviewed literally hundreds of software engineers over the last couple decades for my teams at Microsoft, Adobe, Spotify and other places.

Over the years, I’ve honed in on a few things that I consider vital for anyone joining my organization. These are the kinds of things that I value as a hiring manager, of course. Others will have their own critical criteria.

These are in a rough priority order.

1) Pragmatism
I don’t bother with tricky or difficult programming questions designed to test a corner of your knowledge or some trivia. Instead I ask a dead simple question. Something anyone could do. Then I complicate it. And complicate it again. And again. I look for the point where you can no longer adapt your very first answer. What I want to know is that you are willing to throw away your first answer when it no longer makes sense. You’d be amazed how many engineers will hack on something that will never work when they could throw it away and do something much simpler in a quarter of the time.

2) Interest
Do you actually like writing code every day? Do you read programming blogs for fun? Do you work on your own coding projects outside of work? If this is going to be your job, I want someone who is overjoyed that they get paid to write software. Not someone who’d rather be doing something else.

3) Attitude / humility
I’ve worked with brilliant people who are jerks. For every inch they moved the product forward with their innovation or genius, they moved the project back two inches by being impossible to work with. I want someone who is there to make the team better, not someone who feels like everyone just “needs to do as they are told.”

4) Intelligence
Yeah, you do need to be smart. Writing software is part art and requires creativity, but it is also a lot about problem solving and just sheer brainpower to figure out why this thing is crashing, but only on Tuesday when the moon is full.

5) Programming languages / domain experience
I have worked professionally with a dozen or more programming languages. Some I don’t even remember anymore. While I have a lot of depth in some of them through years of experience, I have been able to learn others as I need to in order to suit the project. I would prefer to see someone with some proficiency in more than one language because that shows some breadth and a willingness to learn, but as long as you can code and are smart (see #4) you can probably pick up whatever language we are working in reasonably fast. I hire for the long term, we can take a bit longer to get you up to speed if you’re a good fit. Similarly with domain experience. If you have an aptitude, we can teach you.

I do have a couple caveats to #5 though:
If I’m hiring for a senior position that requires domain knowledge, yeah, that is in the job requirements, so you need to bring that. You would still need to handle 1-4 though.

On languages, there is a major caveat. If we’re doing C++ or C, you’ll need to have some experience there. If you’ve only ever worked with high-level, garbage-collected languages, it will simply take too long to really bring you up to speed. I’ve tried this too many times in the past and have realized that it usually isn’t worth the effort.

Speaking on the “Teach Parallel” show on IntelTV tomorrow

[crosspost from my adobe.com blog]

Tomorrow morning, I’ll be speaking with Paul Steinberg of Intel and Tom Murphy of Contra Costa college about the criticality of understanding parallel programming techniques for industry.

In my previous role on the Adobe Image Foundation, it was an obvious requirement for our hiring candidates. We were building tools for a insanely parallel problem, image and video processing. Now that I’m working on a new product, it would maybe seem that it would not be as important. In fact, our threading models are even more complicated than in my previous group. My expectations around threading knowledge for incoming candidates are just as high.

Even the most modest mobile hardware is going (or has gone) parallel. In addition, the expectations from a user perspective around interactivity with their applications is never higher. A laggy touch interface is death to an application (or a platform). Going to get coffee while your image renders on a desktop is a thing of the past. User’s expectations of the software we write is higher than ever and it is nearly impossible to get this interactivity without taking advantage of multi-threading on today’s multi-core processors.

The tools continue to improve, but the threading models continue to evolve. A fundamental understanding of multi-threading is critical for anyone moving into Software Engineering or looking to stay current in their field.

I always enjoy talking with Paul and Tom, and expect that we’ll have a lively conversation.

Tune in live on May 17, 10:00 AM PDT

Here is Paul’s post on the subject.