Tech Lead (Backend)

Location: Bengaluru, India

Department: Engineering

Experience: 6 - 8

About Zenskar

Funding

The Problem We're Solving

What Customers Say

"We're saving 200+ hours/quarter on invoicing and receivables by completely automating our recurring billing."

• Noy Kalansky, Finance Controller, Pontera

"Zenskar automates revenue recognition accurately for our value-based billing: agents reducing manual hours by 70%."

• Matt Barnard, VP Finance, Vertice

"Zenskar’s agents automated 90% of our billing, integrated with our CRM, and accelerated revenue collection by a month."

• Ming Lui, VP Finance, Yembo

"Sardine had spent 4 years running billing in-house for high-volume, usage-based pricing. Zenskar took care of it all."

• Sardine team

"We launched our product 4 months faster instead of building an in-house system for our usage-based pricing."

• Kshitij Gupta, CEO, 100ms

About the role

What you'll walk into

1. Re-architecting inter-service communication into an event-driven system, from scratch.
2. Scaling our task management system to handle 10x traffic growth by year-end.
3. Scaling our usage ingestion event pipeline from 10k events/sec to 1M events/sec within the year.

What you'll do

• Turn an ambiguous ask like "the customer wants milestone-based pricing" into interfaces, edge cases, failure modes, and a real migration path
• Design for money correctness by default: idempotency, reconciliation, rounding, proration, audit trail, replay. Assume the system will be wrong somewhere and build in how you'd detect it
• Name and quantify technical debt, and negotiate real bandwidth to address it, rather than silently absorbing it or refactoring unilaterally
• Make the engineers around you measurably better: pair on hard problems, review their work, and be able to point to someone who grew because of you
• Push back on a bad technical decision made by someone more senior than you, when you're right, and make it stick
• Stay hands-on: write and review code at a high bar, day to day, not just in review comments
• Work design and product into your technical plans as you build them, not around them after the fact
• Own production debugging end to end: diagnose across services using logs, traces, and metrics, and make incidents boring instead of fires
• Set architectural direction for your domain: the frameworks, patterns, and abstractions the team builds on for years
• Hold a technical bar in interview loops, and shape who joins the team, without owning the headcount decision
• Stay current on the industry through real people and sources, and be able to name a decision of yours that changed because of something you learned recently

Who you are

• 6 to 8 years of professional software development experience building production systems at real companies
• CS degree or equivalent, with strong fundamentals in data structures, algorithms, OS, and networking

Good to have

• Hands-on observability: comfortable diagnosing complex issues across distributed services using logs, traces, and performance metrics, not just setting up dashboards
• Security and compliance awareness (SOC 2, DPDPA, or similar) with a grasp of the engineering implications
• Experience with event-driven architectures: Kafka, NATS, or RabbitMQ in production
• Cloud platform experience (AWS preferred), deploying and operating services at scale
• Early-stage startup experience: comfortable with ambiguity, evolving requirements, wearing multiple hats
• Background in multi-tenant enterprise software: external integrations, enterprise workflows
• Strong testing culture: unit, integration, and e2e as a default, not an afterthought
• Containerisation and CI/CD: Docker, Kubernetes, GitHub Actions
• Uses AI coding tools like Cursor or GitHub Copilot to move faster without compromising quality
• Experience with financial systems, billing platforms, or fintech applications

What drives you

• You can go deep on the hard problems you've solved: the why, the tradeoffs, the outcome
• You ask "what happens when this fails?" before shipping anything
• You own problems, not tasks: you follow through until the system is healthy, not just until the PR is merged
• You set direction without taking over: you make the engineers around you better instead of becoming the single point of knowledge
• You hold strong opinions on system design loosely, and change your mind when the evidence does
• You thrive where requirements evolve and the answers aren't always obvious
• Not taking yourself too seriously :)

Location

• Hybrid - 3 days per week
• Office Location: Indiranagar, Bengaluru.
• Address: 3rd Floor, A wing No 1, Carlton Towers, HAL Old Airport Rd, HAL 2nd Stage, Indiranagar, Bengaluru, Karnataka 560008.

Interview process

• R0, Recruiter screen (15 to 30 min): Fit, motivation, and a quick check for real, specific experience on cross-functional work, uplifting others, technical debt ownership, staying current, and hiring influence.
• R1, Technical: debugging & correctness (60 min): A small billing-shaped code sample with seeded defects. You walk through it, find what's wrong, including the one nobody would notice for a quarter, and fix the one that matters most, live.
• FAQs for Round 1
  • What should I expect in this round?
  • At the beginning of the interview, you will receive a small, working project containing a few issues. The project will include an existing test suite. Your task is to understand the codebase, investigate the failures, and fix as many issues as you reasonably can during the interview.
  • Will I receive the project before the interview?
  • No. The project will be shared once the interview begins. You are not expected to prepare for or review the specific project beforehand.
  • Will I need to write tests or build a project from scratch?
  • No. The project and tests will already be provided. You are not expected to write new tests or build an application from scratch. We might ask you to code a small extension though.
  • What are you evaluating?
  • We primarily evaluate how you approach an unfamiliar codebase and debug problems systematically. This includes how you:
    • Understand the existing code and requirements
    • Interpret test failures and other signals
    • Form and validate hypotheses
    • Identify root causes
    • Explain your reasoning and trade-offs
    • Make safe, focused changes
  • You are not necessarily expected to find or fix every issue. Your debugging process and reasoning are more important than simply reaching the final answer.
  • Which programming languages are supported?
  • We currently support Java, Python, Go, and JavaScript. Please tell the recruiter which language you would like to use before the interview.
  • If you prefer another language, let the recruiter know well in advance. We will confirm whether the exercise can be made available in that language.
  • What setup do I need?
  • Please have a working local development environment ready before the interview. This should include:
    • An IDE or code editor you are comfortable using
    • The required language runtime and standard build tools
    • The ability to install dependencies, run a project, and execute its tests
    • Screen-sharing access, if the interview is conducted remotely
  • We recommend verifying your setup beforehand so the interview time can be spent on the exercise.
  • Can I use the internet or documentation?
  • Yes. You may use the internet and standard language or library documentation for syntax and API reference. However, AI-assisted tools are not permitted.
  • Can I use AI tools during the round?
  • No. This includes ChatGPT, Claude, GitHub Copilot, Cursor, AI-assisted search, and AI features built into an IDE. Please disable any relevant extensions or integrations before the interview.
  • Should I explain my thought process?
  • Yes. Please talk through your approach, what you are investigating, and why you are making a particular change. The interviewer may ask questions or discuss alternative approaches with you.
  • What if I get stuck or cannot fix every issue?
  • That is okay. Explain what you have learned, what you believe the likely cause is, and what you would investigate next. A structured debugging approach is valued even if you do not complete every fix.
• R2, Technical: design under ambiguity (60 min): A deliberately underspecified, Zenskar-shaped problem. You design it, defend your choices, and reason through a real, resolved Zenskar architecture decision.
• R3, Project deep-dive (60 min): A deep dive into one real project you led, the problem, the non-engineering friction, how you knew it was healthy, and how it shipped.
• R4, Founder / Managerial (60 min): Whether someone is measurably better because of you, whether you've reversed a bad call made above you, whether you've held a hiring bar without owning the decision, and overall fit.
• Reference checks: Two former direct managers, contacted by the hiring manager, including who on your team got better because of you and how they'd know.