How I hire engineers

I once helped out a startup where the departed CTO had come up with what he thought was a clever way to hire engineers. He’d find people who performed very well on coding challenges — he used something like LeetCode — but suffered when they were evaluated for their communication skills. He didn’t need great communicators, he reasoned; he needed people who could program really well.

What a disaster.

The result was an engineering team that could program reasonably well, but were utterly disconnected from the needs of the business. They had a hard time both understanding customer needs, because they weren’t having those conversations, and advocating for themselves when something that was being asked of them was going to be infeasible. The rest of the business treated them as a back office that was handed tasks that they were required to implement rather than a technical partner that could help them figure out elegant solutions.

The engineers were miserable. And the rest of the business thought they were incompetent.

When I arrived, what they asked me for was an excellent product management team. There’s a fallacy, which I’ve encountered in a few places, that if an organization has amazing product managers, they will determine exactly what it is the engineers should be doing, will prioritize tasks, and just tell them what to do. Their dream was that they could just get on with coding — their core skill — and outsource the needs of the business to someone else.

It never, ever works like that. And it shouldn’t. While it’s true that product managers are there to be the stewards of the product’s vision, strategy, and roadmap, they are stewards, not dictators. They get there in collaboration with engineering and design, as well as other stakeholders. At no point do they just dictate what other people will do and absolve engineers from doing that work.

The engineers need to be the technical experts across infrastructure, back-end, front-end, and technical architecture; the designers need to be experts in research, experience, interface, and information architecture. It makes sense that an engineer who finds communication and collaboration hard would just want to be told what to do, but a company that worked that way would be squandering its experts.

Sometimes, very large companies — I’m talking about the Googles and Microsofts of the world — get to hire very deep technical experts in a rare skill. Those people often will go very deep on one thing and act as either a technical consultant or a deep-tech academic researcher for the rest of the company. The rest of us need to hire people with great communication skills who can be strong collaborators and figure out product problems as part of a group of people with different skills and competencies.

So let’s talk about how I do that.

Hiring principles

I think of every team as a community: it’s a group of people who are setting out to achieve a common goal. Granted, it’s not an organic community — everyone’s being paid, for one thing — but the dynamics of any functional community apply.

I think communities work best when:

Everyone is invested in the same mission. Even if their individual goals and values diverge, they’re here to achieve the same thing. It’s not (just) about the paycheck; the work itself has meaning for them. This is particularly important in startups and mission-driven environments where there can be speed bumps in the work itself.

Communication is open and kind. Most startups fail because of preventable human dynamics; that’s also true of teams in other kinds of organizations, like newsrooms. You can’t let friction linger. That means giving and receiving feedback openly. It also means thoughtful communication: speaking inclusively and making sure that conflicts are productive instead of aggressive. Nobody needs to work with shouters, or people who belittle their lived experiences or identities. I’m a big believer in the no asshole rule.

Everyone is treated fairly. If you don’t have an inherent sense of fairness in a community, resentment will build. That means making decisions based on systems rather than whims, so that they’re predictable and observably free of favoritism or bias. It also means making sure that people are compensated fairly for their skills: if someone’s core engineering skills are underdeveloped compared to someone else who’s being paid the same, that will clearly build resentment.

When we grow these communities, I think it’s important that every single person we add brings an underrepresented perspective and an underrepresented skill. As an individual, they should add to the whole. And then those skills and perspectives need to be respected in the course of the work. If someone comes from a particular community and has an opinion about why the business is not going to land for them, or, worse, is harming them — the business needs to listen.

The test

I’ve made an explicit choice not to use LeetCode-style tests or do live coding interviews. I don’t believe that either is representative of the real work.

In both cases, what you’re testing is someone’s ability to recall algorithms and data structures in a high-stress, live setting. It’s closer to a university exam than anything that might happen on a real-world engineering team. In reality, the work — when it’s done well — is contemplative and reflective. While it’s very important to determine what someone’s core technical skills actually are, I’m much more interested in learning how they perform in that more reflective context.

So I’ve arrived at a take-home test.

These are controversial, too: they’re often time-consuming in a way that’s unfair to the participant. At their worst, they ask you to do real work that the business needs, on an unpaid basis. Some organizations have pivoted to actually bringing the person in for a day and paying them for it, but I don’t think that’s a great test either: everybody is deep in onboarding at the start of a new job, so you’re expecting them to leapfrog over the weeks-long stage when they’re in learning mode. It also rules out people who have an existing job or other commitments that make a random day-long engagement impossible.

My take-home tests give the participant seven calendar days to return them, and ask the participant (on the honor system) to spend no more than two hours on them. The goal isn’t to get something with finish and polish; it’s to spend a little time demonstrating the way they think. It’s always a relevant problem to the business but never something we would actually use in production.

One test I’ve used a few times at ProPublica (and I guess now won’t again!) is to ask an engineer to build an unsettled, HTML-only version of the site, using its RSS feed as a de-facto API. Getting to a prototype here is not hard: you use an RSS parser library, you build an interface around it. But it turns out that the choices people make in such a simple project are highly indicative of how they think. The way they handle pages, the way they structure their code internally, whether they comment or not, how they write instructions so reviewers can test. All of those choices are meaningful and inherent to their own internal process, and, as it turns out, bear out in how they do the work once they join the team.

You then review based on a rubric. Intention matters: you want someone with the thoughtfulness to mark their code up so it’s easily reviewable for others. You want someone who organizes their code well instead of writes a series of sprawling scripts. You want someone who provides the right detail for someone to run and test the project effectively.

I always ask a series of 3-4 questions about why they made the choices they did and what they would have liked to have done if they’d had more time. These days, I’ve started to ask if they used AI, and if so, how. (It’s not necessarily a disqualifier, if they did it thoughtfully, and if they’re honest about it.) Those are to be left in the README file. And again, they tell me a lot about how that person thinks. Are they curious? Do they care about the people who will use their work? What’s their mindset?

I don’t need to sit in the room and watch this person over their shoulder while they write their code. Every project I’ve ever received has been meaningfully different. And we’ll talk about their choices later.

The conversation

I try and front-load the take-home. There’s a short screener call first, to make sure expectations are shared: the salary (which I like to be non-negotiable), whether we can hire them at all (different companies have different visa capabilities), what the role actually entails, whether the candidate is an asshole over the phone. (Yes, some are.)

Some candidates will never return the take-home; some won’t pass it. But the ones that do are forwarded to two sets of panel conversations. It’s a huge time commitment for the team, so I try and limit this stage to 4-6 strong candidates.

An engineering panel who will talk about the nature of the work, real technical problems that show up during it, and choices the candidate made in their take-home.

A product panel made up of people who will work closely with the engineer but aren’t engineers themselves. This panel will talk about the non-engineering challenges the team faces, and ask questions that speak to how the engineer collaborates across disciplines.

In both cases, the questions the candidate asks are almost more important than the questions the panel asks. They, once again, speak to how the candidate thinks; what they’re curious about; what’s important to them.

Every individual on the panel evaluates the candidate based on a rubric and leaves their own qualitative notes.

The strongest 2-3 are forwarded to a final executive interview. That’s me! I may also have conducted the screener, or have taken a call to talk about the role informally, so in some cases it’s a loop back; in other cases, it’ll be the first time I’ve met the candidate. Either way, I like to ask them if there’s anything they heard in the previous panels that they’re curious about or want to talk about more, and I like to dig into anything those panels highlighted as questions or concerns in their notes. Once again, the candidate’s questions are probably more important than my own.

I’ll always check references personally, and then make an offer over the phone, answering any final logistical questions in the process.

The work

It’s important that the work itself lives up to these values. There’s no use building a process around fairness if the work itself is whim-based; it’s not reasonable to hire for communication if we don’t value it internally. We can hire for collaborators, but if we treat engineers as back-room workers who just accept tasks, it’s tantamount to a bait and switch. We build the culture of community in part by being careful about who we bring into it, but we have to also do the work ourselves to maintain those standards.

When someone joins a community I’ve helped to build, I’m clear that their first couple of months are learning mode: it’s great if they commit code, but there’s no expectation that they will in the first stages. Instead, I want them to meet all the people they’ll work with, both inside and outside the team, and get to a holistic understanding of the organization, its goals, its flaws, and where the biggest opportunities are. That mostly looks like a lot of conversations, which can be exhausting for an introvert, for example, so there’s plenty of time.

I’ve been proud to hire and work with the people I have. Some of them have, very kindly, told me that they appreciate the emphasis I make on relationships and community-building. That’s important to me: we build technology, but we do it as humans, in service of humans. Whether you’re doing it in a startup, a tech company, or a non-tech organization like a newsroom, it’s important to stay centered on the people. That’s how you build a great team. And that, in turn, is how you do the work well.

Afterword: a quick note

These posts are personal and not affiliated with ProPublica, my current employer. It does not necessarily represent how anyone else hires at any organization I’ve been employed by.

But also: if this mindset appeals to you, I’m hiring! ProPublica is looking for a Director of Product Engineering. You’ll work with a small team of product engineers — and me — to provide mentorship, engineering standards, and hands-on architectural and engineering support. If that sounds good to you, the vacancy is open until January 16. If you’re based in the US and have experience working with small, scrappy engineering teams, please consider joining our community!