Building a Hiring Pipeline

Hero

The Question

Tell me about your approach to building a hiring pipeline for engineering talent. What's worked best for you?

My Core Philosophy¶

I hire for problem-solving ability and communication skills over specific technical expertise. Technology stacks change, frameworks evolve, but the ability to tackle ambiguous problems and work well with others is what makes someone valuable long-term.

The MIDS team from the identity platform improvements is a good example. What those three engineers had in common wasn't a shared tech stack—it was the ability to handle fuzzy requirements independently and contribute to technical decisions.

The Process¶

My hiring process was collaborative—I wanted multiple perspectives on every candidate:

1. Define the Role Clearly¶

I'd create a detailed job description that focused on expectations and capabilities, not just a laundry list of technologies. What problems would this person solve? What ambiguity would they need to navigate? What level of independence did the role require?

2. Multiple Sourcing Channels¶

I worked with our People & Culture team and retained recruiting firms. I didn't rely on a single channel because different sourcing methods surface different candidate pools. The MIDS team came from three different sources, and all three approaches worked.

3. Resume Screening for Technical Fit¶

I reviewed resumes as they came in and made yes/no decisions for initial screening. I was looking for evidence of problem-solving and growth, not just matching keywords to our tech stack.

4. Culture & Values Screening¶

Our P&C team conducted initial screens to assess cultural fit and alignment with organizational values. This saved everyone time—if someone wasn't aligned with how we work, we discovered it early.

5. Panel Interviews with the Team¶

I scheduled at least two panel interviews, each with two team members. This did a few things at once: the candidate met people they'd actually work with, the team had input on who joined them, and we got diverse perspectives on the candidate's fit.

After each panel, we'd meet and discuss. If the hire decision wasn't unanimous, I rarely moved forward. A team that's bought into hiring someone is a team that will invest in their success.

6. My Interview: Problem-Solving & Communication¶

If the team gave a thumbs up, I'd meet with the candidate. My goal was to understand how they solved problems and tackled fuzzy or ambiguous requirements. I'd ask about situations where they didn't have clear answers and how they navigated that.

I'd briefly discuss tech stack, but I didn't dwell on it. I listened to how they communicated and observed how they interacted—both their clarity of thought and their ability to engage in a conversation.

7. Optional Design Session¶

Depending on seniority and role, I might include a whiteboarding session with one of my Staff Engineers to gauge design thinking and problem-solving approach. This wasn't about perfect UML diagrams—it was about how they think through problems and communicate their reasoning.

8. Setting Expectations Upfront¶

If I was happy with the candidate, I'd lay out my expectations before handing off to P&C for the offer:

"I don't know" is acceptable. Nobody knows everything, and I'd rather hear honesty than BS.
Keep your commitments. If you can't—things happen—let me know as soon as you can.
Do your honest best. I don't expect perfect execution all the time. If you fail but learn, I don't see it as failure. We all miss the mark sometimes.

The team usually sold the opportunity themselves. When candidates met engineers who were excited about the work and genuinely enjoyed working together, that was more compelling than anything I could say.

What Worked Well¶

Team-driven decisions: Getting unanimous buy-in meant new hires had advocates from day one. The team invested in their success because they'd chosen to work with them.

Problem-solving focus: Discussing how candidates approached ambiguous problems told me far more than technical trivia questions.

GitHub portfolio discussions: If a candidate had public work, walking through it together was infinitely more valuable than whiteboard coding.

Treating candidates as people: I asked about interests and hobbies, and tried to show genuine interest in them as individuals, not just someone to fill a role. This built rapport and gave me insight into what motivated them.

What Didn't Work¶

Coding challenges: I stopped doing "solve this problem in 30 minutes while someone watches" exercises. They don't represent how we actually work, and they create artificial pressure that doesn't reveal actual capability. Under normal circumstances, those problems would take hours and involve collaboration, not performance under a timer.

I'd still discuss code—principles, design patterns, frameworks—but I wouldn't ask someone to write code with someone looking over their shoulder.

Over-indexing on tech stack: Early in my career, I focused too much on whether someone knew our specific technologies. I learned that smart people who can solve problems will learn whatever stack you're using. Hiring for aptitude and adaptability proved far more successful than hiring for current technical knowledge.

Results¶

This approach worked. The MIDS team delivered the uptime improvements. The consolidated team went from dysfunctional silos to one where 75% of people thrived under raised standards.

The key: hire people who think independently, collaborate well, and tolerate ambiguity. Then support them rather than expect them to figure everything out alone.