Hiring the Wrong Senior Dev — The $300k Mistake and How to Avoid It

Bad senior hire patterns:

1. The FAANG refugee
   → Worked at Google, brilliant at large-scale distributed systems
   → Your problem: 50k users, monolith, 5 engineers
   → Spends 6 months proposing Kubernetes migrations that aren't needed
   → Lacks judgment for startup-stage pragmatism

2. The technical brilliant, socially absent
   → Writes the best code on the team
   → Never communicates blockers until they're on fire
   → Never documents, never shares context
   → Junior engineers learn in spite of them, not because of them

3. The "yes" engineer
   → Agrees with everyone in interviews
   → Never pushes back on bad decisions
   → Doesn't flag scope issues until deadlines are missed
   → Lacks the conviction to defend good technical choices

4. The territorial expert
   → Knows their area deeply
   → Guards it — doesn't want others touching it
   → Creates a knowledge silo that becomes a bus factor

5. The interview-optimized candidate
   → Excellent at LeetCode
   → Average at actual system design
   → Great at memorizing answers to common questions
   → Struggles with genuine ambiguity

// Interview question types that test what matters at senior level

// BAD: "Implement a LRU cache" — tests memorization, not judgment
// BETTER: "You've joined a startup with 3 engineers. The product is slow.
//         What do you do first?"
// Tests: measurement before optimization, prioritization, pragmatism

// BAD: "Design Twitter" — too abstract, no constraints
// BETTER: "Your checkout service is timing out at 2% of requests.
//         Walk me through how you'd diagnose and fix this."
// Tests: debugging methodology, systems thinking, communication

// BAD: "What's the CAP theorem?" — tests memorization
// BETTER: "Your payment database has just had a partition. Customers are
//         checking out — your system can either show them an error or
//         risk double-charging. What do you decide and why?"
// Tests: understanding of trade-offs, business impact reasoning, conviction

// BAD: "Rate your TypeScript skills 1-10" — self-report is noise
// BETTER: "Here's a TypeScript codebase with some problems.
//         Walk me through what you see."
// Tests: actual code reading ability, what they notice, how they prioritize

interface InterviewQuestion {
  type: 'judgment' | 'technical' | 'behavioral' | 'systems'
  question: string
  goodSignals: string[]
  badSignals: string[]
}

// The most predictive interview element is watching someone actually work
// Not a take-home whiteboard — a paid trial on a real (anonymized) problem

const trialProjectGuidelines = {
  duration: '3-5 hours',
  compensation: 'Full hourly rate — this is real work',
  nature: 'Realistic, scoped version of actual work you do',
  what_to_observe: [
    'How do they approach ambiguity — do they ask or assume?',
    'How do they communicate progress and blockers?',
    'What do they notice that you did not tell them to notice?',
    'How do they handle scope they cannot finish?',
    'What does their code look like when they\'re not performing?',
    'Do they document and add observability, or just solve the problem?',
  ],
}

// Example trial project for a senior backend engineer:
const exampleTrial = {
  brief: `
    Here's a simplified version of our order processing service.
    We've been having intermittent failures on high-traffic days.
    We'd like you to:
    1. Review the code and identify potential failure points
    2. Add monitoring to help diagnose production issues
    3. Fix one issue of your choice and explain why you chose it
    4. Write a brief note on what you would tackle next if you had more time
  `,
  timeBox: '3 hours',
  howToEvaluate: 'More interested in approach and communication than completion',
}

Most reference checks fail because they ask questions that get scripted answers.
These questions actually get useful information:

Useful reference check questions:

"What type of problems does [name] do their best work on? Worst work on?"
→ Reveals actual strengths and gaps, not just general praise

"How did they handle a situation where they disagreed with a decision?"
→ Tests conviction and communication (will they push back? how?)

"If I were their manager, what should I know to get the best work from them?"
→ This question gets surprisingly honest answers about management style needs

"Can you describe a time they made a mistake? How did they handle it?"
→ Self-awareness and accountability signal — also reveals whether reference
   is scripted

"Would you hire them again for this role? For a different role? Why/why not?"
→ The most predictive single question — notice if they hesitate on "this role"

"Who else should I talk to about [name]?"
→ If they only offer hand-picked references, ask for skip-levels and peers

Red flags in reference checks:
- References only at their manager level (no peers, no skip levels)
- All praise with no texture or specific examples
- Hesitation before "would you hire them again for this role?"
- Strengths described as soft skills with no specific technical examples

"Culture fit" is often unconscious bias in disguise.
"Culture contribution" is what you actually need from a senior engineer.

Questions for culture fit (often biased):
- "Would I want to get a beer with this person?"
- "Do they seem like us?"
- "Do they communicate like our current team?"

Questions for culture contribution (more useful):
- "What will this person add to our team's capabilities?"
- "Where will this person push back on our existing assumptions?"
- "What kind of problems do they solve that we currently struggle with?"
- "Will junior engineers learn from watching this person work?"

Senior engineers should be hired partly to change how the team works —
not just to fit into how it already works. Some friction is good.
The question is whether the friction is productive (raises quality)
or destructive (demoralizes, creates conflict).

Interview signal for culture contribution:
→ They respectfully disagreed with something in the interview (good sign)
→ They asked questions about the team that showed they were evaluating us too
→ Their past experience is meaningfully different from your team's
→ They have opinions that they can defend with evidence

Signs a senior hire isn't working out (months 1-3):

Week 4-6:
- No code shipped yet (for a coding role)
- Raises problems but has no proposals
- Creates a lot of process discussion, little output

Month 2-3:
- Junior engineers are struggling to work with them
- They've set estimates that bear no relation to actuals
- There's a growing list of "this will take longer than expected"
- Code reviews are blocking rather than teaching

Month 3-6:
- The team is routing around them
- Senior conversations stop including them
- Their projects have been quietly reassigned

If you see Month 2-3 signs:
- Have a direct conversation immediately
- Name specific behaviors, not personality traits
- Set clear expectations for the next 60 days
- Be willing to exit if the behaviors don't change

The kindest thing for everyone (including them) is a fast, clear exit
rather than 18 months of mutual misery.