My Slides From My BBC Develop Keynote

I had a great time at the BBC Develop conference in London this week. The BBC were gracious hosts, the audience had some good (and not too easy questions) and the program had some really good talks; so I learned quite a bit and met some excellent folks. Special thanks to Tanya Rai, Colin Savage, and Simon Stevenson at the BBC for inviting me and putting on a great day.

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.

Some upcoming talks (Stockholm and London)

Since getting to Spotify, I’ve been thinking a lot about what makes a good engineering culture and the best way to create, nurture and protect it. There is no simple formula, but I’m starting to understand better the things that have worked well in both the small startup teams I worked in as well as the big corporate ones. I’ve got two talks coming up where I’ll outline some of these thoughts. I hope that it will be insightful or inspiring to others. At least there will be some amusing anecdotes 🙂

I’ll be doing a short talk on Thursday next week at Valtech Days in Stockholm. My talk is specifically on doing real work using Lean and Agile techniques, based on my experiences building products at Microsoft, Adobe and Spotify. The line-up looks really great. It will be an excellent event.

On November 12th, I’ll be keynoting the BBC Develop 2013 conference in London. This will be a much longer talk where I go into the Spotify model of Lean and Agile development, and how it has grown a strong engineering culture. This event looks really awesome. It should be a really informative day. I’m really looking forward to it.

I’m not sure if either of these will be recorded, but I plan to continue talking about this as I keep working on these issues at Spotify. So if the subject is interesting to you, but you can’t make it, stay tuned.