Skip to content

hiring

  • in hiring
  • 2 min read

The FDE Manifesto: What Would Stokes Do?

This is a version of a document I had written during my time at Palantir.

Stokes was a legendary FDE at Palantir, and I learnt a lot by emulating his way of operating. This wasn't hero worship—it was shorthand for a specific way of operating that separated exceptional FDEs from the rest.

Here are the tactical principles that define that approach.

Never Take Shortcuts That Compound

  • Don't make config changes that aren't product defaults
  • Never restart services "just to see if it fixes things"—you're destroying evidence
  • Never deploy dirty builds. If you're on a branch, getting back to mainline is P0
  • Every custom modification is technical debt with compound interest

Own the Product Stack

  • Clone the repos. Make them build. Start submitting PRs
  • When you get a stacktrace, read it. Form a hypothesis before opening tickets
  • Know the architecture cold—when telemetry fails, it's your only map
  • If a workflow is blocked on a feature, scope it and build it yourself

Treat Information as Infrastructure

  • Ensure logs and metrics are collected properly from day one
  • Master telemetry tools—they're not optional
  • Read everything: docs, runbooks, release notes, support tickets, Stack Overflow
  • Monitor what other teams are encountering—their problems will be yours soon

Root Cause Everything

  • Never accept "it's working now" as resolution
  • Gather data and form hypotheses before implementing fixes
  • You must be able to explain why the product broke and why your fix worked
  • Document your debugging process for future you

Build Strategic Relationships

  • Every support ticket is a relationship-building opportunity with core engineers
  • Contribute field signal to product direction—you're their eyes and ears
  • Know the product team's roadmap and weigh in based on deployment reality
  • Getting your tickets prioritized is a function of relationships, not just severity

The Strategic Thread

These aren't random best practices. They're behaviours that compound into a strategic advantage: radical ownership of outcomes.

When you refuse shortcuts, you're choosing long-term system health over short-term wins. When you master the product stack, you're becoming a peer to the product team, not a consumer. When you root cause everything, you're building institutional knowledge that makes future problems trivial.

This is what makes the FDE model powerful. You're not there to implement solutions—you're there to own outcomes completely. That ownership manifests in these specific, tactical behaviors that seem small but fundamentally change how you operate.

The question isn't whether you can do these things. It's whether you will.

Building an FDE organization? These principles are your hiring rubric. Look for engineers who already think this way.

  • in hiring
  • 3 min read

The Unreasonable Effectiveness of Hiring Assholes

I've seen this pattern play out dozens of times. The brilliant engineer who tears apart your architecture in design reviews. The physics Nobel laureate who's a complete dick but moves research forward. The Palantir FDE who makes people uncomfortable but somehow always ships.

They're assholes. And they get results.

So there's this tempting logic: Maybe we need to hire more of them?

A friend at a startup just told me something interesting. "Everyone here is so humble," she said. Then she paused. "Maybe too humble. Nobody fights for their ideas. Sometimes it feels we're not ambitious enough"

We've created a false choice:

Option A: Hire nice, humble people → Get a room full of diffidence

Option B: Tolerate brilliant assholes → Get results but destroy morale

Is this a true dichotomy?

Were the assholes effective because they were assholes? Or despite being assholes?

What if the causality is backwards?

They had conviction. They were direct. They were ambitious. They pushed back on bad ideas.

They also happened to be assholes.

We saw correlation and assumed causation. We thought the cruelty was necessary for the conviction.

Let me give you a counter-example.

Paul Mustiere spent 8 years at Palantir. I was his mentor when he interned. A few months ago, he joined Comand AI as Head of Engineering.

Paul is one of the highest-agency people I've ever worked with. He gets things done. He'll challenge your technical approach. He'll push back on bad ideas. He sets ambitious visions and rallies teams around them.

He's also genuinely humble. Low ego. Makes people around him better.

You don't have to choose between conviction and decency. Paul is living proof.

But even if you believe tolerating assholes gets short-term results, what's the actual cost?

The good people who quietly leave. The collaborative culture you never build. The institutional knowledge that walks out the door. The junior engineers who learn that being right matters more than being decent.

You're not being pragmatic by ignoring human cost. You're taking on technical debt in your culture. And like all technical debt, it compounds.

So here's the reframe:

Stop asking: "Should we hire assholes?"

Start asking: "How do we hire for conviction, directness, and ambition without hiring for cruelty, ego, and disrespect?"

Because these are separate traits.

You can have the physicist who challenges every assumption AND treats grad students with respect.

You can have the engineer who rewrites your architecture AND makes you feel good about the collaboration.

You can have the leader who sets an ambitious vision AND brings people along.

The framework for hiring:

Must-haves:

  • High conviction (will fight for what they believe)
  • Intellectual honesty (will change their mind when wrong)
  • Directness (will tell you the truth)
  • Ambition (wants to build something great)

Deal-breakers:

  • Making it personal
  • Cruelty for cruelty's sake
  • Ego-driven (caring more about being right than finding truth)
  • Disrespecting people even while disagreeing with ideas

In an interview, this looks like:

  • Someone who challenges your technical approach → good signal

  • Someone who challenges it and makes you feel stupid → red flag

  • Someone who says "I think you're wrong about this architecture" → high conviction

  • Someone who says "I can't believe you'd even consider that approach" → asshole

The unreasonable effectiveness of hiring assholes? It's a myth.

What's actually effective is hiring people with conviction.

Some of them happen to be assholes. That's not the part that makes them effective. That's the part that will eventually destroy your company.

Don't confuse the two.

What's your experience? Have you seen companies successfully separate conviction from toxicity? Or is this just naive optimism?

  • in hiring
  • 5 min read

The Database Selection Trap: Why Your Technical Interviews Might Be Testing the Wrong Things

I recently watched a talented engineer fail a system design interview, and it made me question everything I thought I knew about technical hiring.

The candidate was asked to design a data model for a food delivery platform. They chose PostgreSQL. When the requirements evolved—millions of drivers, real-time location updates, flexible schemas—they couldn't pivot to NoSQL. Despite perfect nudges from the interviewer, they remained stuck.

Here's what haunted me: In any real engineering role, this person would have thrived. They'd have teammates suggesting alternatives. They'd have design reviews. They'd have documentation and prior art to reference.

But in that interview room, artificially isolated from every resource that makes modern engineering possible, they failed.

This isn't a story about lowering the bar. It's about recognizing that many of our "standard" technical interviews are testing the wrong things entirely.

The Comfort of Cargo Cult Interviews

We've all been there. You're tasked with building a hiring process, so you do what seems logical: look at what successful companies do and copy it. Google does system design interviews? So do we. Facebook does algorithm challenges? Add it to the list.

But here's the problem: we copy the form without understanding the function.

That database selection question? It made perfect sense... until I asked myself what we were actually testing: - Can this person independently choose the right database in isolation? - Or can this person build great systems in a collaborative environment?

These are fundamentally different skills. And only one of them matters for the job.

The Three Interview Traps That Filter Out Great Engineers

After auditing dozens of hiring processes, I've identified three common traps that eliminate potentially excellent engineers for the wrong reasons:

1. The Isolation Trap

The Setup: Candidate must solve everything alone, from first principles, without any external resources.

The Problem: This isn't how engineering works. Ever. Modern engineering is collaborative, iterative, and builds on existing knowledge. The best engineers aren't those who can reinvent everything in isolation—they're those who can leverage their team and tools effectively.

Real Example: A senior engineer with 10 years of experience couldn't remember the exact syntax for a specific PostgreSQL window function. In reality, they'd look it up in 30 seconds. In the interview, they struggled for 10 minutes and lost confidence.

2. The Perfection Trap

The Setup: One significant stumble means failure, regardless of overall performance.

The Problem: Engineering is about recovery and iteration, not perfection. Some of the best engineers I've worked with are great precisely because they recognize mistakes quickly and course-correct effectively. But our interviews often punish any deviation from the "perfect" answer.

Real Example: A candidate designed 90% of an excellent solution but made one architectural decision that would have caused scaling issues. Instead of seeing if they could identify and fix it with feedback (like they would in a real design review), they were marked down significantly.

3. The Specific Knowledge Trap

The Setup: Testing specific technical knowledge rather than fundamental thinking.

The Problem: Technology changes. What matters is engineering judgment, learning ability, and problem-solving approach. But we often test whether someone memorized the specific technologies we happen to use today.

Real Example: A brilliant engineer "failed" because they weren't familiar with Kafka. They understood event-driven architectures perfectly and had used RabbitMQ extensively. Given a week on the job, they'd be productive with Kafka. But the interview didn't capture that.

A Better Way: Design Interviews That Mirror Reality

The solution isn't to make interviews easier. It's to make them more realistic. Here's a framework I use with my clients:

Step 1: Start With Role Reality

Before designing any interview, answer these questions: - What does a typical day look like for this engineer? - What resources do they have access to? - How do they collaborate with others? - What does "great performance" actually look like?

Step 2: Map Backwards to Interview Signals

For each critical skill, ask: - What's the minimal signal we need to assess this? - How can we test this in a way that mirrors reality? - What support would they have in the real role?

Step 3: Build in Collaboration and Iteration

Instead of testing isolated perfection, test realistic excellence: - Allow candidates to ask clarifying questions (like they would with stakeholders) - Provide feedback and see how they incorporate it (like in code review) - Let them reference documentation for syntax (like they would with Google) - Focus on their thinking process, not memorized solutions

Case Study: Redesigning the System Design Interview

Here's how we transformed that problematic database interview:

Old Version: "Design a data model for a food delivery system. Choose your database and justify it."

New Version: "Let's design a data model for a food delivery system together. Here's our current scale and requirements. As we go, I'll play the role of your teammate and share what we've learned from our existing systems."

The key changes: 1. Collaborative framing - "together" and "teammate" set the tone 2. Living requirements - Requirements evolve during the discussion, like real projects 3. Historical context - They can ask about existing systems and constraints 4. Focus on reasoning - We care more about how they think through trade-offs than their initial choice

The result? We started identifying engineers who would excel in our actual environment, not those who could perform in artificial interview conditions.

The Hidden Cost of Bad Interviews

Every time we filter out a great engineer because they stumbled on an artificial constraint, we're not just losing a potential hire. We're: - Reinforcing biases toward certain backgrounds (those who've practiced these specific interview formats) - Extending our hiring timeline as we search for unicorns who excel at interviews AND engineering - Building teams that optimize for interview performance over actual job performance

Your Next Step: The One-Question Audit

Pick one question from your current interview process. Just one. Now ask yourself:

"If a strong engineer failed this specific question but excelled at everything else, would I bet they'd fail in the actual role?"

If the answer is no, you're testing the wrong thing.

The Path Forward

Great hiring isn't about finding engineers who can solve puzzles in isolation. It's about identifying those who will thrive in your specific environment, collaborate effectively with your team, and deliver value to your customers.

That means designing interviews that test for reality, not ritual.

Start with one interview. Make it 10% more realistic. See what changes.

Because somewhere out there is an engineer who would be fantastic on your team but can't remember if MongoDB uses documents or collections in the heat of an interview.

Do you really want to miss out on them because of that?

  • in hiring
  • 1 min read

Criticality and Engagement

Hiring is hard. It's difficult to figure out what makes a good hire.

If nothing else I have found these two qualities to be the most important in a hire:

  1. Critical thinking
  2. Engagement

I have often rejected candidates who were technically strong but lacked these two qualities.

Critical Thinking

"The day you don't feel comfortable disagreeing with me is the day we have lost our culture" - Shyam Sankar

Shyam said this in one of the all hands at Palantir and it has stuck with me since then.

You want to hire people who are not afraid to disagree with you. You want to hire people who will challenge you. Independent thinkers is what makes a company.

Engagement

Anyone who is genuinely interested in the work will naturally be a high performer. They will care about getting it right. It aligns incentives.

This attitude is infectious, it is additive. It will rub off on the rest of the team.

Conclusion

Of course there are other qualities that are important, and I have written about them in the past. But these two, to some degree are "must haves". Be on the lookout for them.

  • in hiring
  • 4 min read

Hiring for a mission-driven early-stage startup

I have recently had the privilege of working with the team at Comand AI. Comand is a mission-driven startup that is building a platform to bolster NATO and NATO-aligned countries' defense capabilities by building products that help make operations more efficient and effective.

The company is at a very early stage and are currently sprinting towards finding product-market fit. At the same time they have a very clear mission and vision, and have seen early signs of traction in the market. This means as they continue to gather user feedback and iterate on their product, they need to build a team that can move quickly and adapt to the changing needs of their customers.

The Challenge

The founding team at Comand AI is really strong on the technical side. It is exactly the kind of team you would expect to see at a mission-driven startup - highly motivated, technically strong, and deeply passionate about the problem they are solving. However, they needed help in building out the team further. How do you identify the traits that would make someone successful in a mission-driven startup? How do you build a hiring process that can help you identify these traits?

At the pre-product-market-fit stage you generally want people who have spikes in at least one of the following two areas:

  1. Highly Creative: They need to be someone who can explore the product space and come up with innovative solutions.
  2. Strong Execution: They need to be someone who can take a vague idea and turn it into a product really quickly.

You either need someone who can chart out uncharted territories and come up with innovative ideas, or someone who can quickly build a prototype and test it out with users. Ideally both.

Separately, you need to be mindful of the mission-driven aspect of the company. You need people who are deeply passionate about the problem you are solving, and who are willing to go the extra mile to make sure you succeed. And you need to think about the kind of culture you want to build. You want people who are collaborative, who are willing to take ownership of the outcome, and who are able to work effectively with others.

Designing a hiring process that can help identify these traits is crucial to building a team that can help you achieve your mission.

The Process

I started by understanding the current team makeup, their values, and the business goals they were trying to achieve. This was mapped to the hiring goals for the next 6 months. I also did some ground work by shadowing a few interviews and understanding the current process. This revealed the different interviewing styles, their preferences, the kind of questions they were asking, and the synthesis process.

One of the main gaps I noticed was something I have written about before - being ok with the unfairness of interviews. The team has high empathy for the candidates, and at times this meant they were not making the hard decisions that were needed. An empathetic interviewer is a good thing - being empathetic helps build a genuine connection with the candidate, but while synthesising the feedback, it is important to be objective. This is especially important when evaluating candidates who are good, but not great. At such an early stage, you want to hire great people.

I also worked with the internal recruiting lead to design a process that would help identify the traits we were looking for. This included:

  • A screening call with the internal officer and me to understand the candidate's motivations and values.
  • (Optional) Another domain-specific call with the technical lead to understand the candidate's technical capabilities.
  • Coding assessment.
  • Onsite interviews that included a mix of technical and behavioural interviews.
  • A founder interview to understand the candidate's alignment with the mission and vision of the company.

The first screening call was designed to protect the team's time and ensure that only candidates who were deeply aligned with the mission and vision of the company were brought onsite.

We are still in the process of iterating on the process, but the early signs are promising. The team is excited about the candidates they are seeing, and the candidates are excited about the opportunity to work at Comand AI. As we get more reps under our belt, we hope to add more rigor and accountability by introducing hiring theses to have a historical record of why we made the decisions we did, as well as to have an understanding of how and where to staff new hires.

Looking Forward

As Comand AI continues to grow, they will need to continue to iterate on their hiring process. They will need to think about how to scale the process, how to ensure that the process is fair and unbiased, and how to ensure that they are hiring the right people for the right roles. And all of this without losing sight of the mission and vision of the company. But the passion and drive of the founding team was apparent since the beginning, and I am confident that they will be able to build a team that can help them achieve their goals.

Get in touch if you would like to work at Comand AI, or if you would like to know more about the hiring process we are building. I am always happy to chat about hiring, startups, and everything in between. If you are currently in the process of hiring for your startup, and would like some help, feel free to reach out to me at me@anjor.xyz.

  • in hiring
  • 4 min read

A Hiring Framework for a New Kind of Services Company

These past couple of weeks I have been working closely with the team at Northslope Technologies on designing a hiring framework.

The Challenge

Founded by former Palantirians, Northslope is a professional services company that provides premium Foundry & AIP development services. This shape of the company is unique in that it is a professional services company that has a product component, and still relies on elite technical talent to deliver services. This makes hiring a unique challenge.

On one hand you can't hire in the same way as you would for a consulting company. You want to hire people who will take ownership of the outcome, and not just be a pair of hands. On the other hand, you can't hire in the same way as you would for a product company. While building reusable product components is important for efficiency and scalability, the primary focus remains on delivering high-impact client outcomes, on short timeframes.

This means we need people who can balance both mindsets - who can leverage Foundry's capabilities to deliver client solutions efficiently, while also identifying opportunities to build reusable components that amplify our impact across multiple engagements.

The Framework

Given this unique challenge, we have been working on a hiring framework that is designed to identify and attract the right kind of talent. It starts with two key questions:

  1. Are they smart?
  2. Do they want to win?

In some sense this is all you need to know about a candidate. If they are smart, they will learn and grow quickly - both on the technical side and on the business side. They will be creative, resourceful, and able to solve complex problems. If they have a desire to win, they will be able to deliver high-impact client solutions, build reusable product components, and help grow the business. They will be able to work effectively with clients, understand their needs, and deliver solutions that exceed their expectations.

This is obviously an oversimplification. If this is all we had on our hiring scorecard we would be missing a lot of important details. It also is highly subjective and prone to bias. But it is a useful starting point. Let's break it down further.

What Does It Mean to Be Smart?

  • Problem Solving: Are they analytical? Do they demonstrate empirical, evidence-based thinking? Can they break down complex problems into simpler components?
  • Creativity: Are they able to think outside the box? Can they come up with innovative solutions to problems?
  • Execution: Are they able to build a working solution? Can they take an idea from concept to reality?
  • Customer Focus: Are they able to understand the needs of the client? Can they deliver solutions that meet or exceed their expectations?

What Does It Mean to Be Able to Win?

  • Getting Things Done (GTD): Are they able to deliver results? Can they execute on their ideas and deliver high-impact solutions?
  • Ownership: Are they able to take ownership of the outcome? Can they drive projects to completion and take responsibility for the results? Do they demonstrate a commitment to excellence?
  • Low Ego: Are they able to work effectively with others? Can they collaborate with clients and team members to deliver solutions that meet everyone's needs?
  • Criticality: Are they able to identify opportunities for improvement? Can they see the big picture and understand how their work fits into the larger context?
  • Grit: Are they able to persevere in the face of challenges? Can they overcome obstacles and setbacks to achieve their goals?
  • High Chaos Tolerance: Are they able to thrive in a fast-paced, high-pressure environment? Can they adapt to changing circumstances and deliver results under tight deadlines?

The Process

We have developed an interview process that reflects these dimensions while remaining adaptable and evolving. Currently, it centers around three core components:

  1. An open-ended problem decomposition interview, where candidates work through an intentionally ambiguous challenge. This helps us evaluate their analytical thinking, creativity, and ability to navigate uncertainty - critical skills for client-facing work.

  2. A technical analysis and building exercise that assesses not just technical capability, but how candidates approach building solutions in practice.

  3. A behavioral interview that explores past experiences and approaches to challenges, helping us understand how candidates embody traits like ownership and grit in real-world situations.

Looking Forward

But perhaps more important than the specific format is our commitment to continuous refinement of the process itself. We regularly evaluate how well these interviews predict success in the role and adjust accordingly. This mirrors our broader approach at Northslope - we're building something new in the professional services space, and that requires being thoughtful and deliberate about every aspect of how we operate, including how we grow our team.

  • in hiring
  • 5 min read

Context Matters

Hiring is often viewed as a universal process -- "hire the best engineers, obviously!" -- but the reality is far more nuanced.

Hiring is deeply context-dependent, and understanding this can make the difference between building a thriving team and struggling with misaligned talent. As someone who has worked extensively in hiring and team building, I've observed firsthand how crucial it is to align your hiring strategy with your company's current stage, technical needs, and overall vision. This blog post discusses three distinct scenarios I've recently encountered while consulting for different clients, each facing unique hiring challenges.

Through these examples, we'll explore:

  1. How a solo founder can build their founding team
  2. The approach an early-stage startup should take when scaling their engineering team
  3. Why a Series A startup needed to shift focus from engineering to operations

Each case study offers insights into the critical thinking required to design effective hiring processes that go beyond simply filling roles. We'll discuss how to identify the truly important traits for each context, how to redesign job descriptions to attract the right candidates, and how to create interview processes that effectively evaluate the skills and attributes that matter most.

By the end of this post, you'll have a deeper understanding of why one-size-fits-all hiring rarely works, and how to approach hiring strategically based on your company's specific context and needs.

Client 1: A solo founder hiring their founding team

I am working with a product-minded solo founder with a ML background who is looking to hire their founding team. Since they don't have a software engineering background, designing the right hiring process was a crucial problem to solve.

We started by identifying the critical first hire - an engineer who could help drive the technical vision of the company. The job description they had in place had a ton of technical jargon and was focused on the wrong things. The critical insight here was while being pre-pmf, the first couple of engineers need to have spikes in one of the following two areas:

  1. Highly Creative: They need to be someone who can explore the product space and come up with innovative solutions.
  2. Strong Execution: They need to be someone who can take a vague idea and turn it into a product really quickly.

As you are trying to find your PMF, you need to be able to iterate quickly and try out a bunch of different things. This means you need to hire for speed and creativity, not for scale and robustness.

Once we aligned on this, we redesigned the job description to focus on these two areas and started sourcing candidates from our network. We also started working on a technical interview process that would help us identify these traits in candidates using techniques from my previous posts on hiring.

Client 2: An early stage startup looking to scale

This client is an early stage startup with about 10 engineers looking to scale to 20-30 engineers in the next 6 months. They have a couple of products showing early signs of traction and are looking to build out their engineering team. The current team is very product-focused and has a strong engineering culture. They are looking to hire engineers who can come in and start contributing to the product quickly and autonomously. The kind of profiles they are looking for are similar to the Forward Deployed Engineer role at Palantir.

This was obviously an area I have a lot of experience in. The key value add here was helping them design a hiring process that would help them identify engineers who could come in and start contributing quickly. This was done by first shadowing the current interviews and identifying the key areas where they were struggling to evaluate candidates - this could be questions they were asking, or the way they were synthesising the signal from the interviews. I then gave the interviewers feedback on what's working well, and areas where they could improve. I even conducted a few interviews myself to help them calibrate their bar.

Even when you know what you are looking for, it is not always easy to evaluate it in an interview. This is where having an experienced interviewer can make a big difference. During the interview, it is important to be ruthlessly objective about the signal you are getting. This means you form a hypothesis about the candidate, and then try to disprove it with your next question.

Client 3: A series A startup looking to expand their operational team

This was a very different problem to solve. The core technical and operational strategy of the company relied more on the operational team than the engineering team. Despite this their focus was on hiring engineers, and they were struggling to find the right profiles, and to keep them engaged once they joined.

The key insight here was that the operational team was the bottleneck in the company's growth, and they needed to hire for that team first. Once we aligned on this, we started working on a hiring process for the operational team. We also worked on hiring a few key engineers who could help the operational team scale - this had a much wider impact than hiring engineers directly.

It is important to be true to your company's needs and not get caught up in the hype around hiring engineers. Sometimes the most impactful hires are not in the areas you initially think. Having those honest conversations with the founders can make a big difference in the hiring strategy.

Conclusion

Through these engagements I learned a lot about how context matters in hiring. Here are a few key takeaways:

  1. Align with Your Stage: Whether you're pre-PMF, showing early traction, or entering a growth phase, your hiring needs will vary dramatically. Prioritize the skills and attributes that will drive your company forward at its current stage.
  2. Look Beyond Technical Skills: While technical proficiency is important, factors like creativity, execution speed, and cultural fit can be equally, if not more, crucial, especially in early-stage companies.
  3. Adapt Your Process: Your hiring process should reflect your company's needs and culture. Whether it's designing creative technical interviews, focusing on operational skills, or prioritizing autonomous contributors, tailor your approach to find the right fit.
  4. Understand Your Bottlenecks: Sometimes, the most impactful hires aren't in the areas you initially think. Be open to reassessing your needs and focusing on the roles that will truly drive your company's growth.
  5. Continuously Refine: As your company evolves, so too should your hiring strategy. Regularly reassess and adjust your approach to ensure you're attracting and selecting the talent that aligns with your current and future needs.

Effective hiring is not just about filling roles; it's about building a team that can execute on your vision and drive your company forward. By understanding the nuances of your company's context – its stage, culture, and strategic goals – you can design a hiring process that not only attracts top talent but also ensures that talent is the right fit for your specific needs.

Remember, the goal isn't to hire the "best" people in absolute terms, but to hire the right people for your context. This mindset shift can make all the difference in building a team that's truly equipped to tackle your unique challenges and opportunities.

  • in hiring
  • 2 min read

Interviews are Unfair

And that's ok.

As I have mentioned before, genuinely connecting with the candidate makes you an effective interviewer. Having high empathy for the candidate helps build that genuine connection. However, that makes it easy to fall into the "fairness trap".

Fairness Trap

"Fairness trap" is where you, the interviewer, hold yourself to a high standard of fairness. You want to do right by the candidate. It is natural - you have just spent a solid amount of time going through their background, and other interviewers' feedback, and then spent an hour or so interviewing them yourself - it makes sense that you feel a connection. But this connection can cloud your judgment, especially when evaluating candidates who are good, but not great.

Hiring is Existential

For early-stage companies, hiring is existential. Each new team member can significantly impact the company's trajectory. While you might have predetermined criteria for ideal candidates, meeting these baseline requirements isn't always enough.

When evaluating a candidate, consider:

  • What new capabilities will this hire bring to the team?
  • How much potential for growth does the candidate have?
  • What is their "ceiling" - the maximum impact they could have on the company?

These questions help you look beyond surface-level qualifications and consider the candidate's long-term value to your organization.

While data and criteria are important, don't underestimate the value of your intuition. Trust your gut feeling about a candidate, but be aware of your own biases.

Empathy and Objectivity

The key to effective interviewing lies in balancing empathy with objectivity:

  1. During the interview: Build a genuine connection with the candidate. Show empathy and create a comfortable environment for open discussion.
  2. After the interview: Step back and evaluate objectively. Consider the candidate's fit, potential, and possible growth trajectories within your company.

Conclusion

Interviews are inherently unfair because they can never capture a person's full potential or fit within a short interaction. However, by acknowledging this limitation and consciously balancing empathy with objectivity, we can make more informed hiring decisions.

Remember, the goal isn't just to be fair to the candidate in the moment, but to make the best decision for your company's future. Sometimes, that means passing on a good candidate in hopes of finding a great one.

Hiring Theses

Hiring exceptional candidates is hard. In previous posts I have written about how one might go about identifying and interviewing strong candidates consistently.

In this post I would like to share a technique at the final stage of the hiring process that I have seen used at Palantir and Protocol Labs, and have found to be quite effective - namely, the hiring thesis.

What is a Hiring Thesis?

A hiring thesis is a comprehensive document prepared by the hiring manager after making a decision to hire a candidate. It serves as a summary of why they chose this particular individual, highlighting their strengths and qualities that make them an ideal fit for the company.

This is not just a list of their strengths and weaknesses but a nuanced and thoughtful document.

Key components of a good Hiring Thesis

  • What projects or workstreams will this candidate have an outsized impact on? And what specific qualities will make that happen?
  • What is this candidate's ceiling? Is that an acceptable level and why?
  • What is this candidate's kryptonite? What projects/people should this candidate absolutely not work on/with?
  • What is the best case scenario?
  • What is the worst case scenario? How might we mitigate this?
  • Any advice for managers about what to look out for to help this person succeed?

Why is a Hiring Thesis important?

It might seem like a lot of overhead to write this document for every hire, however, it is a useful exercise for multiple reasons.

  • It increases confidence in the hiring decision by forcing you to consider multiple different scenarios
  • It provides as a guide for their manager for things to watch out for, staffing decisions etc.
  • It builds up a knowledge asset for the company and helps calibrate future interviewers/hiring managers.
  • Parts of the hiring thesis could also be used as a sell chat for the candidate!

Conclusion

The hiring thesis is a powerful tool that can significantly enhance your hiring process and set new team members up for success. By taking the time to articulate your thoughts and expectations for each new hire, you create a valuable resource that benefits not just the individual, but the entire organization.

Implementing a hiring thesis process may require some initial effort, but the long-term benefits far outweigh the investment. It promotes more thoughtful decision-making, provides a roadmap for employee development, and contributes to a culture of intentional growth within your company.

Ultimately, the hiring thesis is more than just a document—it's a commitment to nurturing talent and fostering an environment where both individuals and the company can thrive. By adopting this approach, you're not just filling positions; you're strategically building the future of your organization, one carefully considered hire at a time.

Get in touch by emailing me@anjor.xyz if you are an early stage startup looking to improve your hiring process.

How did Palantir hire so well?

I have written before about the Forward Deployed Engineer profile, and how hiring for that profile can be highly impactful for a company -- Palantir being a great example. In that blog post I also wrote a bit about how to hire FDEs. But honestly, re-reading that post I realised that the framework I wrote down though helpful to orient, does not give the means to assess whether or not your hiring is going well.

One Hiring Manager

That got me thinking -- how did Palantir do it so well? What was the secret? Unfortunately, the answer is not an easy one. Palantir did things that do not scale for their hiring. During the time I interviewed there, there was 1 hiring manager for all engineering hires. This one individual was responsible for:

  • Gathering feedback from all the on-site interviews a candidate has been through: 3 per candidate.
  • Based on the synthesised feedback, design a bespoke hiring manager interview for the candidate that would gather signal that was missed during the on-site interviews.
  • After the interview, if decided to hire the candidate, write a thorough hiring thesis for the candidate.

These were just the actual interviewing responsibilities. This same hiring manager was also the lead for the whole recruiting machinery:

  • Working with recruiters to put together top of the funnel strategy.
  • Working with leadership and resourcing to understand headcount and/or specific geographical/profile needs.
  • Designing and running the internship program.
  • And most importantly recruit and calibrate new interviewers.

Conclusion

By centralising the hiring function there was immense quality control over the hiring. But as you can imagine, it is hard work and can result in the individual burning out.

Like any other aspect of building a startup, this is a tradeoff. At early stage companies I do recommend founders and/or founding team to be involved in hiring as much as possible. You know your company and its culture better than anyone else. As you scale, if you can find an individual who is willing to take on the hiring function and keep it centralised as much as possible that is ideal for maintaining high quality bar.

Need Help with Your Hiring Strategy?

If you're looking to improve your company's hiring process, I can help. I offer:

  • Tailored hiring strategy development
  • Interviewer training and calibration
  • Guidance on building a hiring function

Whether you're a startup founder or an HR leader in a growing company, let's discuss how to elevate your hiring to the next level. Contact me for a free consultation.