N. Harrison Ripps

In Decemeber of 2014 I transitioned from fifteen years of being a developer into being one of the people managers on a really amazing team here at Red Hat. All told, my first year in this role has been a tremendous learning experience for me. If you are interested in becoming a part of a team like this one, here is some advice for you based on the dozens of interviews I have conducted over my first 15 months.

1. Do Your Homework

A little basic Googling will reveal that I currently work for Red Hat and that I am involved with the Project Atomic and OpenShift projects, both of which are open-source and are hosted on GitHub. If one of our awesome recruiters sets you up for an interview with me, they will also tell you about these projects. When this happens, read up on the projects.

I know that you may already have a day job, and outside of work your life may be just as busy – but time-boxing 15 minutes to learn the basics of the project you are being interviewed to work on seems reasonable to me. I’m going to ask you: “what do you know about $project?” and you should be able to come back with “I checked it out on GitHub and here’s my understanding of the system…” If you can’t do that, you’re either a recent college grad and I give you the benefit of the doubt, or you’ve been working long enough to know better and you come across like an artiste whose genius must certainly exempt you from things like reading ahead.

2. Put Your Best Code Forward

If you already work in open source, you can probably point to a GitHub repository with some of your commits in it. That’s great, particularly if the commits are extensive and show a solid contribution to whatever project you worked on. On the other hand, if you are coming from a closed-source company, or don’t have any high-profile commits, I encourage you to code a sample application and publish it in a public repository.

When I first joined my current team as a developer, I had been working expressly in private corporations with private code repositories. My interviews went reasonably well, but with no working code to point to, the team was hesitant to commit. The interviewing manager asked me to pull together a code sample and suggested that since I was interviewing to work on OpenShift, then I ought to write an app that would work on OpenShift. I put my weekend plans aside and spent 48 hours cobbling together this goofy farmstand search application.

That code is old and somewhat bit-rotted now. I also wrote it in Node.JS, having never worked with it before my weekend hack-a-thon. In the balance, though? Probably the most important weekend in my professional career.

3. Be Ready to Dive Deep on What You Know, and Know When You Don’t Know

As I talk to you during our interview, I’m going to try to figure out where on our team you could be a good fit. Once I’ve started to dial that in, I’m going to start asking more specific questions. I want to understand the level of technical depth that you possess. I don’t have perfect knowledge of all of the technologies that we work with, but if I’m reasonably comfortable with your skills then I am going to have you interview you with someone who can go really deep on that stuff.

So, be ready to talk through multiple levels of the technology that we discuss, and also be ready to tell me when you’ve hit the extent of your knowledge on a given topic. I’d rather spend the remaining time in our interview talking through other technologies rather than having you improvise on a topic that you don’t really know.

Also – don’t be surprised or offended if we ask you some college-level questions about data structures, or sorting complexities. If we’re asking you, it is because these things are directly relevant to the work that you are being considered for. We want our systems to work quickly and efficiently at cluster scale, so this stuff is pretty important.

4. Show Me Your Team Face

My main responsibility to the company as a people manager is to put together the best team to work on the projects that I’m a part of. A large part of this is making sure that new hires have the technical chops to do what is expected, based on their level of expertise. But there are a number of other skills that mean a lot to me. I’m talking about the stuff that we collectively refer to as Emotional Intelligence.

I’m not a psychologist, but I know how a good team operates, and I want to make sure that your participation is going to be a net positive for my team. Sure, I want to hire rock stars – but if we make an engineering decision as a team that you personally disagree with, you’ve got to be able to let your own position go for the benefit of the team. So the challenge to you is to convince me that you can accept the team’s decision even if you don’t believe it is the right approach.

I will ensure that you always have the opportunity to speak your mind, but you’ve got to convince me that you can live with the team decision. This is a huge part of getting things done in an open-source environment.

Seem Reasonable?

Hopefully none of what I’ve said sounds outlandish, or like I’ve got a particularly puffed-up view of my team and my company. Naturally, I think my team at Red Hat is the best team in the business. In fact, bonus advice: if you are considering a job in open source, don’t work for a manager who doesn’t think their team is great.

But more to the point, I think the items that I outlined in this article will be helpful for you at any company that’s doing real open-source work. And even if you aren’t looking right now, putting up some code samples for even the most basic application that you can think up is an easy way to start “building your brand” as a developer.

If you end up interviewing with me, I can’t guarantee that following this article to the letter will land you a job offer. But on the other hand, it will certainly make you stand out to me and the recruiters that I work with.

Good (job) hunting!

Discuss...