We’re looking for a senior, hands-on engineer who can own meaningful product and technical problems from the first unclear conversation to a healthy production rollout.
This is primary a backend role. This is not a role where seniority means moving away from code.
You will not have direct reports by default. Your leverage comes from sound decisions, clear execution, strong reviews, and making it easier for other engineers to contribute.
Billing experience is not required. A healthy respect for correctness is.
What you'll walk into
Our backend is primarily Python and Postgres on AWS, running a multi-tenant platform. Prior experience with this exact stack is useful, but not required.
The software moves money and sits between customers’ CRM and ERP systems. The interesting failures are often not loud exceptions—they are retries, duplicate actions, partial state, unclear audit trails, slow workflows, and an edge case that quietly creates the wrong invoice.
At the same time, finance teams should not need to understand our architecture to use the product. SDE3 engineers help make complex rules feel simple without hiding operational risk.
Projects you might work on
The exact project depends on product priorities, but SDE3-sized work could include:
•Building multi dimensional pricing model in core billing engine to help support our clients’ complex billing needs
•Scale our clickhouse server to handle 5x data growth we foresee over the next year.
•Make our CRM/ERP integrations reliable by ensuring retries, idempotency, status visibility, recovery, and customer-facing failure states are present.
•Build AI Agent to help parse contract PDFs reliably
Your first 30 days
The first month is about building context quickly while remaining useful. By the end of 30 days, we expect you to have:
•Learned the core journey from customer contracts and usage data to invoices and revenue workflows.
•Shipped several safe changes, including at least one production bug fix.
•Participated in a real production investigation and understood the relevant logs, metrics, and operational tools.
•Reviewed code and established working relationships with product, design, solutions, and engineering peers.
•Identified one medium-sized problem to own and written or contributed to a clear technical plan.
•Asked enough questions to expose assumptions rather than quietly building the wrong thing.
By 90 days
By the end of 90 days, you should be operating as the clear owner of a meaningful project or milestone. That means you can:
•Turn an ambiguous goal into an agreed scope, design, delivery plan, and set of explicit risks.
•Make and defend decisions across APIs, data, failure modes, reliability, and operability.
•Break work down so one or more engineers can contribute effectively.
•Plan migration, backward compatibility, rollout, monitoring, and recovery—not bolt them on after implementation.
•Ship a meaningful milestone and verify its correctness and product outcome in production.
•Own at least one difficult production investigation through diagnosis, mitigation, and follow-up.
•Provide useful code and design reviews that improve both the implementation and the engineer.
•Explain what should happen next: remaining risks, technical debt, product gaps, and the next sensible investment.
A strong 90-day outcome is not “completed every ticket.” It is “created clarity, shipped something meaningful, and left the system and team easier to operate.”
Who you are
•You have roughly 5–7 years of professional software-development experience; scope and evidence matter more than an exact year count.
•You have personally shipped and operated production systems used by real customers.
•You remain comfortable coding, debugging, reviewing changes, and reading unfamiliar systems.
•You have deep backend experience and can work across APIs, data, asynchronous processing, infrastructure, and production operations.
•You have owned at least one substantial project through production and can explain your personal decisions and outcomes.
•You work effectively with product, design, customer-facing teams, and engineers with different levels of experience.
•You have helped other engineers become more effective through reviews, pairing, planning, or mentorship.
Good to have
None of these are mandatory:
•Python, Postgres, AWS, or distributed-systems experience.
•AWS, Docker, CI/CD, background jobs, or event-driven systems.
•Experience with multi-tenant B2B software and external integrations.
•Hands-on observability using logs, traces, metrics, and production profiling.
•Billing, payments, accounting, fintech, or revenue-automation exposure.
•Experience using AI coding tools without outsourcing judgment or understanding.
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
Our process is practical and evidence-based. The live technical rounds are capped at 60 minutes; the project/HM conversation is 90 minutes with a short reset.
•R0, Introductory conversation: A 15–20 minute conversation about role alignment, current scope, hands-on engineering, location, compensation, and motivation.
•R1, Debugging and correctness: A 60-minute practical exercise in Python, Java, or Go using a small existing codebase and supplied tests. The goal is to diagnose and safely correct consequential problems—not solve an algorithm puzzle.
•R2, Technical design: A 60-minute deliberately underspecified, Zenskar-shaped design problem. You will clarify it, design an implementable solution, discuss failure and evolution, and drill into one component.
•R3, Project and Hiring Manager deep dive: A 75-minute conversation with the Hiring Manager: one substantial project in depth, followed by collaboration, feedback, mistakes, mentoring, motivation, and the environment in which you do your best work. No presentation is required.
•R4, Engineering Leadership: A final 30 -minute conversation with our Head of Engineering or CTO about engineering judgment, product and business trade-offs, your growth trajectory, and Zenskar’s direction. It is assessed, but there is no additional coding or system-design exercise.
During technical rounds, documentation and syntax search are allowed. AI can help only with syntax or an isolated generic utility; it cannot solve, debug, or design the interview problem for you.
Candidate FAQs
Common technical-round FAQs
•Which programming languages are supported? - Round 1 is available in Python, Java, and Go. Tell the recruiter your preferred language before the interview. The problem, tests, and evaluation criteria are equivalent across languages; niche language trivia is not assessed.
•Can I use the internet or documentation? - Yes. Standard language and library documentation, web search, and syntax references are allowed.
•Can I use AI tools? - Yes, within a limited boundary. AI may help with syntax, standard-library reference, or a small isolated generic utility that can be described without the interview problem. Tell the interviewer before using generated code and be able to explain and change it.
•What AI usage is not allowed? - Do not share the problem, repository, tests, failures, stack traces, domain models, or error messages. Do not ask AI to design, implement, debug, or review the interview solution. Repository-aware chat, agent mode, and problem-aware autocomplete are not allowed.
•Why is limited AI allowed? - We are not testing memory for syntax, and engineers use modern tools at work. The boundary keeps the candidate’s reasoning visible and the assessment comparable.
Round 1 FAQs
•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.
Round 2 FAQs
•Is this a whiteboard or internet-scale system-design round? - It is a discussion-based design round, but the scope is a realistic product or service problem. We want an implementable design, not memorised architecture for a social network.
•Will product-facing behaviour be discussed? - Yes, when relevant. You will not be assessed on frontend implementation, but you should reason about how API behaviour, failures, permissions, retries, and long-running operations affect clients and customers.
•Can AI generate or critique my design? - No. The limited-AI policy does not permit AI to solve, review, or improve the interview design.
Round 3 FAQs
•Do I need to prepare a presentation? - No. Choose one substantial project you understand deeply and be ready to discuss the problem, your personal decisions, delivery, collaboration, production outcome, and what you would change.
•Can the example come from a failed project? - Yes. A project that did not meet its goal can still provide strong evidence if you show ownership, judgment, learning, and a clear understanding of what happened.
Round 4 FAQs
•Is the Engineering Leadership conversation assessed? - Yes. It assesses engineering judgment, connection to product and customer outcomes, communication with leadership, and growth trajectory. It is also a chance for you to evaluate Zenskar.
•Will there be another coding or design exercise? - No. Expect a conversation grounded in real decisions from your work, followed by time for questions about Zenskar’s product and engineering direction.
