Video summary

Getting Hired In Post AI World (My Experience)

Main summary

Key takeaways

Business

Business Hiring Takeaway: “Hiring Style Needs to Change” (Especially for Founding Roles)

  • For a founding back-end / founding engineer (i.e., the #1–#3 hire with major decision-making responsibility), the bar is about autonomy + judgment, not just implementation ability.
  • Interview design should be more personalized and less reliant on generic coding-only questions.
  • Technical rounds must not be outsourced to non-technical interviewers who score asynchronously using AI. The round should be human-led (or at least human-reasoned in real time).

Playbook / Interview Format Framework (Semi-Structured)

Recommended Structure (Interviewer’s Process)

  • 5–10 minutes: Introduction + background
    • stack experience
    • hard problems solved
  • 20–25 minutes (sometimes more): Solve a company-relevant problem via whiteboarding
    • interviewer watches approach and reasoning, not just the final architecture

What the Interviewer Is Evaluating

  • How quickly the candidate understands requirements
  • Whether the candidate can make good architecture choices and justify tradeoffs
  • Awareness of AI-agent realities:
    • deployment
    • tooling
    • model selection
    • data privacy
  • Ability to ask the right clarifying questions at the right time
  • Reasoning clarity:
    • explaining tradeoffs
    • costs
    • scale implications

Less “Coding Questions,” More “System Design + Tradeoff Reasoning”

The interview de-emphasizes “loaded” micro-debug questions (e.g., a dependency bug in useEffect) as the main focus.

Instead, the emphasis shifts to:

  • whiteboard system design
  • cost/complexity reasoning
  • operational concerns:
    • deployment
    • caching
    • rate limiting
    • error handling
  • scalability assumptions and how architecture changes with scale

Concrete Interview Case Study (AI + Law/Healthcare Lead Qualification Workflow)

Context

  • Startup domain: AI + law (US; healthcare/law-specific lead area)
  • Marketing: Facebook lead ads generate leads
  • Backend receives lead data (e.g., email, phone number) and runs an AI agent workflow

Problem Statement (What to Design)

Build an AI conversational agent that:

  • contacts the lead on Telegram
  • runs a human-like text conversation flow
  • collects specific data/files sent by the user
  • stores results back in the backend

Also include an admin dashboard that:

  • shows ongoing chats and what the AI is doing
  • allows admins to intervene / jump into a session
  • supports AI handoff (“I’m done collecting data”) and admin interrupting mid-flow

Operational / Architecture Elements Expected

  • Webhooks and event-driven ingestion (Facebook → backend)
  • Telegram APIs + Telegram webhooks for user replies
  • System components for:
    • persistence (example mentioned: Postgres)
    • queuing/caching/rate limiting (example mentioned: SQS, Redis)
    • AI agent orchestration (example tooling mentioned: Universal AI SDK or custom harness)
    • deployment environment (example mentioned: AWS Lambda or EC2)
    • dashboard support for live monitoring and admin takeover
    • model choice + privacy concerns
      • e.g., if a candidate mentions “open weights,” interviewer may ask about not sharing training data

Scale-Based Tradeoff Prompts (Cost/Complexity vs Usage Logic)

The interviewer explicitly tests whether the candidate adjusts architecture based on realistic volume.

Example Scale Assumptions Introduced

  • < 10 leads/day
  • < 20 messages/lead
  • => effectively ~100–200 messages/day

Evaluation Goal

  • If the candidate chooses SQS (or adds queueing complexity), the interviewer asks whether they’d change decisions given low volume.
  • Intent: apply “YAGNI via scale”—justify complexity only when it’s warranted.
    • e.g., removing unnecessary components
    • possibly using Postgres-based queuing instead
    • using Redis only if truly needed

Framework: “Dynamic Interview” Loop (Clarifying Questions + Course Correction)

  • The interview is not static; the interviewer uses follow-up constraints to test adaptability.
  • Candidates should:
    • infer missing requirements
    • ask clarifying questions early (not only after designing)
    • reason through components even if they haven’t built that exact system before

Key Principle

  • AI tools may “just start working” with ambiguous instructions.
  • Humans must detect ambiguity and ask better questions.

AI-Era Hiring Skill Gap: “AI Is Bad at Asking the Right Questions”

Observed issue: raw AI harnesses may:

  • proceed with incomplete context
  • drift into a different direction, requiring later correction

The interviewer looks for a candidate who naturally:

  • requests scale, constraints, and privacy expectations early
  • demonstrates fundamentals that lead to better question selection

Actionable Recommendations

Candidate Preparation

  • Don’t interpret “less coding questions” as “less coding/system knowledge.”
  • Strong fundamentals are still required:
    • programming + micro/macro system understanding
    • system design competence (including database basics like Postgres)
    • performance/cost reasoning and component boundaries
  • Practice via hands-on learning (not only passive watching).

Interview Execution (Time + Reasoning Traces)

The interviewer also provides practical feedback observed from candidates:

  • Respect the time box (example: 30 minutes); don’t overshoot with too much non-technical talk.
  • Show reasoning aloud (“reasoning traces”):
    • approach
    • alternatives considered
    • tradeoffs/cost impacts
    • when a missing requirement becomes clear

This is framed as more natural for humans than for LLMs (which can’t interrupt reasoning mid-stream as flexibly).

Metrics / KPIs Explicitly Mentioned

The only explicit KPIs were system-scale quantities used for design reasoning:

  • leads: < 10/day
  • messages: < 20/lead
  • total messages/day: ~100–200/day

No business KPIs (e.g., revenue, CAC, LTV, churn) were provided in the subtitles.

Presenters / Sources

  • Presenter/Source: the interviewer/content author narrating their “my experience” (no additional named sources or co-presenters mentioned).
  • Sponsor mentioned: Filmora (AI video workflow sponsor; not directly tied to the hiring/business process content).

Original video