Ep #4: Head of Engineering @SarvamAI | Hiring Engineers, AI Jobs & Career Advice

SarvamAI’s Mission & Competitive Strategy (Why “Sovereign AI”)

SarvamAI is pursuing sovereign AI focused on:

• Indian language performance
• Deployment control, including air-gapped / on-prem needs for some government and military use cases

Competitive angle vs frontier model labs (e.g., OpenAI/Anthropic)

Sarvam positions itself against frontier labs on two main fronts:

• Native-script Indic output

  • Frontier models may answer in Indic languages, but often in Latin script.
  • Sarvam claims stronger performance in native-script Indic language understanding and generation (e.g., Gujarati → Gujarati script, Marathi → Marathi).

• Speech & call center automation

  • Sarvam targets speech and call center automation, where existing TTS/ASR may struggle across Indian languages.

Key technical proof points mentioned

• Sovereign 105B model
  • Described as Sarvam’s “biggest model we have” in their stack.
• 22 official Indic languages (SOTA claims across)
  • LLM performance in native language script
  • ASR (speech-to-text) and TTS (text-to-speech)
  • Downstream usage such as voice interactions (mic → STT → response)

High-level positioning

Sarvam frames its mission as bridging the gap between:

• generic frontier capabilities, and
• India-native usability, especially for voice and Indic languages

It also highlights sovereignty in contexts where you may need models:

• without guardrails (in some cases)
• for self-hosting

---

Founder/Leadership Principles (What Sarvam Values)

Extreme customer obsession

• Teams must own problems end-to-end (avoid “it’s not my problem”).
• Reliability and UX are prioritized even when impact appears small.

Extreme honesty

• No “playing with investors’ money”
• No hidden fees
• Honesty with both users and investors

Hard work + alignment

• Leadership and senior engineers should be deeply passionate about the mission/problem.
• Example behavior: late-night founder-to-leader check-ins and continued hard work.

Hands-on ownership mindset

• Engineers should revert quickly on bad releases when needed.
• Avoid leaving customers in a broken state while “debugging.”

---

Concrete Example (Customer Obsession in Operations)

At a prior company (Inmoney):

• 1 user couldn’t access the app overnight
• The team changed core infrastructure paths:
  • networking
  • VAF
  • CDN
  • request routing to backend containers
• At the time, they already had ~1.6 crore users
• They did not optimize based on revenue or user status—the goal was reliability for every user

Takeaway: reliability and responsiveness matter even when “customer influence” seems low.

---

Hiring & Talent Strategy at Sarvam (How They “Take Bets”)

What they do NOT optimize for

• They don’t look at college.
• They don’t filter based on whether someone comes from service companies.

What they DO optimize for (signal-based hiring)

• Passion for the specific work/domain
  • They assess growth curve and motivation.
• Project trajectory / upward technical shift
  • Look for people who moved from narrower roles (e.g., BI) to deeper areas (e.g., model development/inference/core engineering), progressing over time—eventually to principal level.
• Open source contributions
  • They look for whether someone:
    • understands issues,
    • contributes, or
    • at least opens PRs.
• Systems depth (“grow down the stack”)
  • Backend/infrastructure understanding is treated as a proxy for debugging ability.
  • They value understanding infra interactions (e.g., networking and how systems run).

Upskilling playbook (because AI talent is scarce)

Sarvam admits a shortage of “highly talented” candidates (notably agent/platform builders, inference engineers, etc.).

Their strategy:

• Hire smart + passionate people
• Give 4–5 months to study the domain deeply
• Claim: this approach “has never happened” that a brilliant/passionate hire didn’t deliver

Freshness model

• They mentioned they don’t have engineers with >1 year experience (implying early-career/fresher hiring + fast capability-building).
• They assert high success for: “fresher ~6 months and then experienced on the job.”

---

College/Career Guidance (Engineer Skill Strategy)

They believe AI will automate “general backend work,” so they advise differentiation through:

• Domain nuance
  • Ability to explain the business in one prompt (described as “prompting nuance = value”)
• Infra & systems expertise
  • Kubernetes, networking
  • Databases: Postgres/MySQL/ClickHouse
  • Airflow, Kafka
• GPU/accelerator literacy
  • Understanding Nvidia GPU / Apple GPU optimization

Rule of thumb: become an expert in the niche area you’re passionate about—not just generic coding.

---

Performance Management, OKRs, and Firing Process (Organizational Tactics)

• OKRs for KPIs
  • Explicit targets and quantitative thresholds.
• Clear consequences
  • As referenced, a very high appraisal in consecutive quarters can lead to letting someone go.
• PIP / extended support with empathy
  • Put on PIP
  • Provide time and guidance to find better-fit roles
  • Emphasis: employees can land quickly elsewhere; the goal is a better fit
• Framing:
  • Decisions are hard, but handled with empathy and clear feedback.

Culture constraint

• A “politics allergy” policy:
  • Avoid encouraging non-constructive criticism
  • Criticism without the other member present in the meeting is disallowed

---

Engineering Operating Rhythm: Reviews & Unblocking

• Review cadence:
  • Bi-weekly reviews
  • Monthly reviews
  • For important products: weekly reviews
• Leadership time allocation:
  • 60–70%: unblocking + problem solving
  • Remaining time: hiring + strategic decisions (including rewrite and buy vs build)

---

Delivery Mindset: “Own the Problem” and Avoid Customer Pain

• They dislike hearing:
  • “It’s devops/team’s problem” when systems are down or error rates spike.
• Release incident handling principle:
  • Instant revert after a bad release
  • Avoid long debugging that keeps customers on a broken release (even for ~1 hour)

---

Engineering Leadership: “Forward Deployed Engineer” Role Concept

A “forward deployed engineer” role is described as:

• New/market role
• Higher requirement for:
  • communication
  • stakeholder management
• More autonomy:
  • makes engineering decisions directly with clients
  • fewer internal approvals compared to platform roles
• Still requires strong core engineering capability (not “less engineering”)

---

OKRs & Interview Hiring Mechanics (How They Evaluate Candidates)

Interview philosophy

• Avoid short-termist hiring:
  • not “hire fast, fire fast”
• Interviews are long:
  • typically 4–5 hours
• AI is allowed in interviews:
  • they evaluate how you communicate with AI (control vs letting it “run loose”)
• Format:
  • more like tech reviews of existing work
  • they don’t ask DSA questions
  • they judge quality of shipped work

Their “strong yes” requirement

• They look for a strong yes signal from the interviewer/team member.
• If resume depth is unclear, they may:
  • have junior team do the first interview
  • report impressions for decision-making

Concrete red flags observed (review segment)

• They penalize negativity/complaining about the current org.
  • Example: unnecessary criticism about how/why things are bad in a prior role.
• Even with impressive work, they recommend the recruiter confirm attitude:
  • Are they problem-solving oriented?
  • Or do they question why the problem exists?

---

AI Jobs & Where Sarvam Is Investing (Roles / Talent Scarcity)

They mentioned hiring clusters across the AI stack:

• LLM pipeline
  • pre-training, post-training, RL environment creation
• Model development & inference engineering
• Audio models, vision models
• Agent AI development and auto-improvement (called out as “new”)
• Harness engineering / agent platform building

They also noted:

• “We don’t have people… it’s very very hard to find” for these categories
• hence the “hire right + expect them to learn” model

---

Metrics / KPIs / Targets Explicitly Mentioned

• Customer scale example:
  • 1.6 crore users (at a previous company during a reliability incident)
• OKR/IP appraisal cadence:
  • not fixed numeric targets (as presented), but:
    • quantitative goals per KPI
    • decisions based on consecutive quarters
• Hiring/learning model:
  • 4–5 months to study the domain
  • fresher ~6 months, then experienced on the job
• No specific figures were provided for revenue/CAC/LTV

---

Firefast vs Slow Hiring (Their Stance)

Sarvam rejects “hire fast, fire fast”:

• slow hiring
• longer interviews
• deliberate firing tied to OKRs

---

Present / Source Listing

• Presenter / Interviewee: Sunonny (Head of Engineering, SarvamAI)
• Other referenced persons: Vive (co-founder), Pratush/Pratish (co-founders), Ashish, Vikalp Sahani (founder/co-founder of iKakare), and Vikalp (as mentioned in the discussion).