Why We Stopped Hiring from FAANG. The Cost of 'Google Scale' Habits.

We hired ex-Google and Meta engineers. Their resumes were impeccable. Stanford degrees. Worked on systems serving billions of users. Brilliant technical minds.

They also failed miserably at our 50-person startup.

They wanted custom tooling for everything ("At Google, we used Blaze"). They over-engineered simple features for "scale" we didn't have ("What if we hit 100M QPS?"). They couldn't function without a specialized support infrastructure (SREs, QA, DevTools teams).

It wasn't their fault. They had been trained for a different sport. They were NFL linebackers trying to play rugby.

We stopped hiring them. Here's what we look for instead.

Section 1: The 'Google Scale' Mindset

Big Tech engineering is a specific discipline. It's about:

• Consistency at massive scale
• Preventing catastrophic failure
• Optimizing 0.1% efficiency gains
• Navigating complex internal bureaucracy

At Google, if you verify a change for 3 weeks before shipping, you're prudent. At a startup, you're dead.

The Tooling Trap:

FAANG engineers are used to the world's best internal tooling. Build systems that handle monorepos effortlessly. Deploy systems that are fully automated. Observability tools that are magic.

When they join a startup and see Jenkins scripts and console logs, they freeze.

First instinct: "We need to build better tooling."

They spend 3 months building a custom deployment framework instead of shipping the product feature we hired them for.

Section 2: Over-Engineering for Imaginary Scale

A startup problem: "We need to store user preferences."

Startup Solution: Add a column to the Postgres `users` table.

FAANG Solution: "Postgres won't scale if we hit 1 billion users. We should build a dedicated microservice backed by Cassandra with a Redis write-through cache and an async queue for consistency."

They aren't technically wrong. If we had 1 billion users, the Postgres column would fail.

But we have 5,000 users. And if we spend 6 weeks building the microservice instead of 1 hour adding the column, we'll run out of cash before we ever get to 10,000 users.

They optimize for problems we might have in 5 years, ignoring the problem we do have today (survival).

Section 3: The Specialized Infrastructure Dependency

At Meta, you don't rack servers. You don't manage DB backups. You don't write your own QA frameworks.

There are teams for that.

At a startup, you are the SRE. You are the QA. You are the DB admin.

Our ex-FAANG hires struggled with this breadth. "Who handles the load balancer config?" "You do." "Is there a team to write the integration tests?" "You are the team."

This "learned helplessness" regarding infrastructure paralyzed them. They were used to being pure code-writers in a highly supported environment.

Section 4: The 'Startup Native' We Hire Now

We pivoted our hiring strategy. We stop optimizing for prestige brands.

We look for:

1. The "Zero to One" Builder:

Engineers who have built side projects. Freelancers. Founders of failed startups. People who have had to ship code to survive.

2. Pragmatists over Purists:

We ask: "How would you build X?" If they start with Kubernetes and Kafka, we pass. If they say "Django on Heroku until it breaks," we hire them.

3. Generalists:

People who know a little bit about everything (database, frontend, CSS, deployment). Full stack is a lie at Google. It's a necessity at a startup.

Conclusion

Hiring from FAANG feels like a safe bet. "Nobody gets fired for hiring an ex-Googler."

But context matters. A Formula 1 driver is a great driver, but they'll struggle to drive a rally car through the mud.

Startups are mud. You don't need drivers who need a pit crew of 20 to change a tire. You need drivers who can fix the engine with duct tape while driving 80mph.

Hire for the stage you're in, not the stage you hope to be.