10 — Startup-Specific Interview Preparation

Priority: HIGH — You’re targeting startups specifically. This is what differentiates a startup interview from a Big Tech one. Your 5 years at a startup are your SUPERPOWER here.

Table of Contents

1. What Startups Look For vs Big Tech
2. Your Startup Advantage
3. Startup Interview Formats
4. Wearing Many Hats — Show Your Range
5. Product Thinking for Engineers
6. Moving Fast Without Breaking Things
7. Handling Ambiguity
8. Evaluating Startups (Due Diligence)
9. Equity & Compensation
10. First 90 Days Framework
11. Resources

What Startups Look For vs Big Tech

What startup interviewers are ACTUALLY evaluating:

1. Can this person build things end-to-end?
   → Not just write code, but design, build, deploy, and operate

2. Will they thrive with ambiguity?
   → Sometimes requirements change mid-sprint, or you're building
     something with no clear spec

3. Do they care about the product, not just the tech?
   → Engineers who understand WHY they're building something make
     better technical decisions

4. Can they work independently but collaborate when needed?
   → You won't have a manager telling you what to do every day

5. Will they take ownership beyond their "job description"?
   → At a startup, everyone pitches in

6. Are they a culture add, not just a culture fit?
   → Small teams need diversity of thought

Your Startup Advantage

You’ve been at a startup for 5 years. Frame every answer through this lens:

Things You Can Say (That Big Tech Engineers Can’t):

✅ "I've owned the entire backend — from API design to database
   optimization to deployment and monitoring"

✅ "I've worked directly with every team — product, frontend, data,
   and leadership — to make architectural decisions"

✅ "I've built systems handling multi-terabyte data from scratch,
   not just maintained existing ones"

✅ "I've been in the room when product decisions were made and
   contributed technical perspectives that shaped the roadmap"

✅ "I know what it's like to be on-call for a system I built,
   and that accountability makes me build more reliable systems"

✅ "I've made pragmatic technology choices — PostgreSQL + Redis +
   RabbitMQ — because I've learned that boring technology works"

Potential Weaknesses to Prepare For:

❓ "You've only worked at one company for 5 years. How do I know you
   can adapt to a different codebase/culture?"

→ "I've constantly adapted within Intensel — our tech stack and
  architecture has evolved significantly. I've also explored Rust
  and Go outside of work, built open-source projects, and I'm
  currently deepening my distributed systems knowledge through DDIA.
  I'm a fast learner who actively seeks new challenges."

❓ "How do you handle working with other backend engineers after being
   the sole backend person?"

→ "I'm excited about it. Being the only backend engineer means I've
  missed out on peer review and learning from others' approaches.
  I actively seek feedback and learn from open-source codebases.
  I'm looking forward to a team where I can both teach and learn."

❓ "Can you work in a different domain?"

→ "Climate risk involved geospatial data, time-series analysis, and
  real-time processing — pretty different problem domains under one
  umbrella. The core skills — designing APIs, optimizing databases,
  building reliable distributed systems — are domain-agnostic."

Startup Interview Formats

Startup interviews are often less standardized than Big Tech. Common formats:

Typical Startup Pipeline (4-6 rounds)

Round 1: Recruiter/Hiring Manager Screen (30-45 min)
  - "Tell me about yourself"
  - Why you're looking, what you want
  - High-level technical discussion
  - Salary expectations (they'll ask early!)

Round 2: Technical Screen (45-60 min)
  - Live coding (LeetCode Medium-ish)
  - OR take-home project (2-4 hours)
  - Focus: working code > perfect algorithm

Round 3: System Design (45-60 min)
  - Design something relevant to their product
  - They want to see your thought process
  - More practical, less theoretical than Big Tech

Round 4: Deep Dive / Cultural (45-60 min)
  - Walk through a past project in detail
  - Behavioral questions
  - "How would you approach X at our company?"

Round 5: Founder/CTO Chat (30-45 min)
  - Culture fit / values alignment
  - Your vision for the role
  - Questions about the company

Round 6 (sometimes): Paid Trial Day or Take-Home
  - Some startups do a paid trial (1 day or 1 week)
  - Build something real or fix actual bugs

Take-Home Projects (Common at Startups)

Tips:
- Ask for a clear scope and time expectation
- Treat it like production code:
  - README with setup instructions
  - Clean commit history
  - Tests for critical paths
  - Error handling at boundaries
  - Docker setup if applicable
- Don't over-engineer: do what's asked well
- Add a brief "What I'd improve with more time" section
- Show your actual workflow: meaningful commits, not one big commit

Your stack for take-homes:
  - FastAPI + PostgreSQL + Redis (your comfort zone)
  - Docker Compose for easy setup
  - pytest for tests
  - Alembic for migrations
  - Clear API documentation (FastAPI gives you Swagger for free)

Wearing Many Hats — Show Your Range

Startups need engineers who can go beyond “just coding.” Demonstrate breadth:

The Full-Stack Backend Engineer

Architecture & Design
├── API design (REST, versioning, pagination)
├── Database schema design and optimization
├── System architecture (monolith → services)
├── Message queue patterns
└── Caching strategies

Development
├── Feature development (Python/FastAPI)
├── Database management (PostgreSQL/PostGIS)
├── Background job processing (Dask, RabbitMQ)
├── Performance optimization
└── Testing (unit, integration, load)

Operations
├── AWS infrastructure (EC2, RDS, S3)
├── Docker containerization
├── Deployment and CI/CD
├── Monitoring and alerting
├── Incident response
└── On-call rotation

Cross-Functional
├── Working with product to scope features
├── Communicating technical constraints/trade-offs
├── Mentoring junior engineers
├── Technical documentation
└── Data analysis and reporting

How to Show This in Interviews:

Instead of: "I built the API"
Say: "I designed the API, set up the database schema, configured the
     AWS infrastructure, built the CI/CD pipeline, and am responsible
     for keeping it running in production"

Instead of: "I used PostgreSQL"
Say: "I chose PostgreSQL for our use case because of its geospatial
     extensions and ACID guarantees, designed the schema, optimized
     queries as data grew to terabytes, and set up replication"

Instead of: "I worked with the team"
Say: "I collaborated with the product team to scope features, with
     frontend engineers on API contracts, and mentored junior engineers
     on backend best practices"

Product Thinking for Engineers

Startups love engineers who understand the business:

Questions to Ask Yourself About Features:

1. WHY are we building this?
   → What user problem does it solve?
   → What metric does it move?

2. What's the simplest solution that delivers value?
   → Can we validate with an MVP before building the full thing?
   → What's the 80/20 — 20% effort for 80% value?

3. What are the trade-offs?
   → Speed vs. quality vs. cost
   → Build vs. buy vs. open-source

4. How will we know if it works?
   → What metrics define success?
   → How do we measure them?

Show Product Thinking in Interviews:

"When designing the map tile service, I didn't just think about
technical implementation — I considered the user experience.
Pre-rendering tiles at common zoom levels because most users view
at certain scales. Implementing progressive loading so users see
something immediately. Adding caching policies based on actual
usage patterns, not just technical defaults."

"For the data pipeline, I implemented priority queues not because
they were technically interesting, but because customer-facing
requests needed to feel instant, while batch processing could
wait. The technical decision was driven by business priority."

Moving Fast Without Breaking Things

This is the startup balance. Show you understand it:

Pragmatic Engineering Principles:

1. Ship early, iterate often
   "The first version doesn't need to be perfect. Ship an MVP,
   get feedback, then improve."

2. Choose boring technology
   "PostgreSQL, Redis, RabbitMQ — proven technologies that let
   you focus on business logic instead of fighting infrastructure."

3. Build for today, design for tomorrow
   "Write clean interfaces so you CAN scale later, but don't
   build for 10x traffic you don't have yet."

4. Automate the painful things
   "If you deploy manually, you'll make mistakes. If you test
   manually, you'll skip tests. Automate deployments and critical
   test paths."

5. Technical debt is a tool, not a sin
   "Sometimes taking a shortcut is the right business decision.
   Track it, plan to pay it down, and be transparent about the
   trade-off."

6. Tests where they matter most
   "Test the critical path. Test the money path. Test the data
   integrity path. Don't aim for 100% coverage — aim for
   meaningful coverage."

How to Talk About This:

Interviewer: "How do you decide when to take on tech debt?"

You: "I evaluate three things: the blast radius if it fails, how long
the shortcut will persist, and whether we can ship without it. For our
data pipeline, I initially wrote a simpler single-threaded processor
because we needed to demo to investors. Once we closed funding, I
redesigned it with distributed workers. The key is being intentional
about debt, not accidental."

Handling Ambiguity

At Startups, Ambiguity Is Normal:

Scenario: "Hey, we need to support a new data source. Figure it out."

What startups want to see:
1. Gather Context
   "What data formats? How much data? How often? Who needs it?"

2. Propose Options
   "Option A: Quick adapter, ships this week, tech debt
    Option B: Generalized ingestion framework, takes 2 weeks,
    handles future sources too"

3. Make a Recommendation
   "I'd do Option A now because we need to close this customer.
   Then prioritize Option B next sprint."

4. Execute Autonomously
   Don't wait for a detailed spec. Build, get feedback, iterate.

Interview Questions About Ambiguity:

Q: "How do you handle unclear requirements?"
A: "I gather what context I can, make explicit assumptions, share
   them with stakeholders, and build the simplest thing that works.
   I'd rather ship something slightly wrong and correct course than
   wait for perfect clarity that may never come."

Q: "What do you do when you disagree with a product decision?"
A: "I share my technical perspective and the trade-offs I see.
   If the team decides to go a different direction, I commit to
   that decision and make it work. I've found that the best ideas
   come from respectful disagreement."

Evaluating Startups (Due Diligence)

Before You Apply

Research:
- Crunchbase: Funding history, investors, team size
- LinkedIn: Team backgrounds, growth rate, attrition signals
- Glassdoor/Blind: Reviews (take with grain of salt)
- Product: Actually USE the product if possible
- GitHub: Open-source repos? Code quality?
- Blog: Engineering blog shows culture and pride

Green Flags 🟢

- Clear mission and product-market fit indicators
- Funded with 18+ months runway
- Experienced founders (not first-time with no experience)
- Engineering-friendly culture (tech blog, open source, talks)
- Defined technical roadmap (they know what they're building)
- Reasonable interview process (respectful of your time)
- Competitive compensation (salary + equity)
- Team members who've been there 2+ years
- Work-life balance mentioned without being asked
- Clear growth path for engineers

Red Flags 🔴

- Can't clearly explain the product/value proposition
- Funding situation is vague or precarious
- High turnover / team is mostly < 6 months
- "We're like a family" (often means poor boundaries)
- No technical leadership (CTO is non-technical)
- Rewrite everything from scratch plans
- On-call with no compensation or support
- Interview process takes months or is disorganized
- Lowball salary justified by "equity will make you rich"
- No diversity in the team
- "We work hard, play hard" (often means burnout)
- No code review process or testing culture

Questions to Assess During Interviews

- "How much runway do you have?" (>18 months = healthy)
- "What's the path to profitability / next funding round?"
- "How do you handle on-call and incidents?"
- "What's the biggest technical challenge right now?"
- "Why did the last person in this role leave?"
- "How are technical decisions made?"
- "What's the deploy frequency?"
- "Tell me about a recent postmortem."
- "How do you manage tech debt?"

Equity & Compensation

Understanding Startup Compensation

Total Compensation = Base Salary + Equity + Benefits + Bonuses

Base Salary:
- Startups typically pay 10-30% below market for comparable roles
- The equity is meant to make up the difference (and more, if lucky)
- Know your market rate (levels.fyi, Glassdoor)

Equity Types:
- Stock Options (ISO/NSO): Right to buy shares at a strike price
- RSUs: Shares granted directly (more common at later-stage)
- ESOP: Employee Stock Ownership Plan

Key Terms to Understand:
- Vesting Schedule: Typically 4 years with 1-year cliff
  Year 1: 0% (cliff) → 25% at 12 months
  Year 2-4: Monthly or quarterly vesting of remaining 75%
  
- Strike Price: What you pay to exercise options
- 409A Valuation: Company's fair market value (lower = better for you)
- Dilution: Your % shrinks with each funding round
- Liquidation Preference: Investors get paid first
- Exercise Window: How long you have to exercise after leaving
  (90 days is standard, but some companies offer longer)

Evaluating an Offer

Questions to ask:
1. "What's my ownership percentage on a fully diluted basis?"
   (Not just number of shares — percentage matters)
2. "What's the current 409A valuation?"
3. "What's the vesting schedule? Is there a cliff?"
4. "What's the exercise window after leaving?"
5. "How much dilution is expected in the next round?"
6. "What's the company's path to liquidity (IPO/acquisition)?"

Rule of thumb for evaluating equity:
- Assume equity is worth $0 when comparing offers
- If the base salary works for you, great
- Equity is upside, not guaranteed compensation
- Early-stage = more equity, more risk
- Later-stage = less equity, less risk, higher salary

Negotiation Tips

1. Always negotiate: Startups expect it
2. Negotiate base salary first (most reliable)
3. If salary is firm, negotiate:
   - More equity
   - Signing bonus
   - Extended exercise window (1-2 years instead of 90 days)
   - Remote work / flexibility
   - Learning budget
   - Better title (costs them nothing)
4. Get everything in writing
5. Take at least 48 hours to consider any offer
6. "I'm excited about this opportunity. Based on my research and
    experience, I was expecting X. Is there flexibility?"

First 90 Days Framework

Show interviewers you’ve thought about your ramp-up:

Days 1-30: Learn & Listen

- Understand the codebase, architecture, and deployment process
- Set up local development environment
- Ship a small PR in the first week (bug fix or small feature)
- Meet everyone: 1:1s with all team members
- Understand the product from the user's perspective
- Read all documentation and runbooks
- Shadow on-call rotations
- Ask questions: "Why was X built this way?"

Days 31-60: Contribute & Validate

- Own a medium-sized feature end-to-end
- Start participating in architecture discussions
- Identify and fix a pain point in the development workflow
- Start giving meaningful code reviews
- Understand the business context: customers, revenue, roadmap
- Document anything you found confusing during onboarding

Days 61-90: Own & Lead

- Own a significant feature or system area
- Propose improvements based on observed pain points
- Contribute to technical roadmap discussions
- Start mentoring if there are junior engineers
- Have a clear picture of your medium-term focus areas
- Check in with manager: "Am I meeting expectations?"

In Interviews, Say This:

"In my first 30 days, I'd focus on understanding your codebase,
architecture, and product deeply. I'd ship a small PR in the
first week to get into the deployment flow. By day 60, I'd be
owning features end-to-end. By day 90, I'd have a clear picture
of where I can have the most impact and start proposing
improvements. I've done exactly this at Intensel, just from the
other side — I've onboarded new team members and know what makes
a successful ramp-up."

Resources

• levels.fyi: Compensation data for tech companies
• Crunchbase: Startup funding, investor, and team information
• Glassdoor / Blind: Company reviews and salary data
• The Holloway Guide to Equity Compensation: https://www.holloway.com/g/equity-compensation
• Patrick McKenzie on Salary Negotiation: https://www.kalzumeus.com/2012/01/23/salary-negotiation/

My Notes

Companies I'm targeting:
-

Offer comparisons:
-

Negotiation notes:
-

Back to: README.md