I am Mitchell Hashimoto, Founder and CTO of HashiCorp. Ask me anything!

View other answers to this thread
Sandeep Panda's photo

Hi Mitchell

Thanks for the AMA. ❤️ Big fan of Hashicorp and the Open Source projects you have built. I have the following 3 questions for you:

  • In your opinion, what is the best way to recruit and retain a great team?
  • What are some interesting ways to promote and monetize Open Source work?
  • What non-technical aspects do you examine when hiring engineers?

Lastly, do you think cats are cuter than dogs? 😃

Mitchell Hashimoto's photo

In your opinion, what is the best way to recruit and retain a great team?

I think our principles cover the core things best: hashicorp.com/our-principles

I think above everything else, people want to work at a place that is friendly, they feel respected, and there is humility. Egos are not fun, political games are not fun, being attacked or harassed is not fun (also just wrong), etc. It doesn't matter how rewarding the work you're doing is, I think these qualities override that.

Once you have that in place, you can focus on ensuring people have rewarding things to work on. Or, if they're not particularly rewarding, ensure that they have a path to rewarding things. Let's face it: some stuff we have to work on is a slog, its not fun but has to be done. That's okay. But timebox that, be able to say "we have to do this the next 6 months, but then we'll make sure you get to work on something different." As a manager, I think its your responsibility to helping your reports achieve their goals while also being happy. So, the manager should be thinking about this.

What are some interesting ways to promote and monetize Open Source work?

Monetization is still hard. I think Adam Jacob did a good job for listing business models here: sfosc.org/business-models The business model that'll work for you is highly dependent on the type of software you've created.

Monetization to me means: a business. When people say "how do I monetize open source work" the question is really "how do I start a business?" That's important because I think people sometimes think: "how do I get paid to write code on this project" but the REALITY is far far more complex: writing code is a tiny aspect, how do you build a business? Do you even want to build a business?

If you don't want to build a business, you have only one option: get paid to write code through the patronage of someone else. That means donations or employer-sponsored or whatever. The downside to this is you have zero control over your destiny, the patron has 100% control of your destiny. If they decide to stop funding you next week, then whelp, you're out of luck.

There are interesting companies like Tidelift attempting to help maintainers monetize. I think there is a big need for that for sure, but I don't see that as a panacea for the maintainer to be able to just dedicate time to their project. I think you'll inevitably be stuck with support, training, etc. at a bare minimum.

What non-technical aspects do you examine when hiring engineers?

Non-technical aspects are the primary thing I and our company examines when hiring engineers. I hate to break it to most engineers, but being able to understand systems, code, etc. is not the hard part. It's not what makes an engineer special. Of course we expect technical ability, but this quality isn't particularly difficult to find.

Our interviews primarily examine teamwork, conflict management, and alignment with our principles: hashicorp.com/our-principles Kindness, humility, pragmatism. These are things that are unfortunately much more difficult to find!

Concretely, one of the interview questions (a coding question) we ask is impossible in the time we give you to do it. We give you a task that would take maybe 60 or more minutes and give you 15 minutes to do it. Yes, we expect you to do something technically correct, but we're mostly interesting in how you react non-technically. Oh also, the code we give you to get started with is hideous, poor quality, poor tests, also straight up broken in places.

Some people react with anger: "this isn't fair! its impossible! only idiots would write code like this!" Well, that's not very nice (and seriously, we've heard it all here). Some people react by being totally frozen, they have no idea what to do because the time constraint is too much. That's not the point either. Some people fixate on the fact that the code is so ugly, and start cleaning it up. 15 minutes later, they've done nothing except make whitespace line up. Yikes. What we're looking for is someone who says: "okay, I don't think I can do everything, but what's most important is some of X, some of Y, and what you get in the end is Z." It isn't complete, but its an improvement, and they've justified the improvement. Just one example...

Lastly, do you think cats are cuter than dogs? 😃

I'm a dog person. 🐶 Sorry! twitter.com/mitchellh/status/10508730786143..

Mark's photo

So your interview would involve giving me horrible broken code, impossible deadlines, and then I'll be spending that time justifying why it has to be fixed first? I'm not sure I'd want to work there after that...