Software Engineer – Systems & Reliability Smallest.ai | Bangalore
About The Role Own a service or a part of our product from design through production. You’ll write the code, validate its behaviour, deploy it and keep it reliable for the customers who depend on it. Testing, deployment and operations are part of engineering ownership here. You’ll work with the team, but you won’t hand off responsibility when your code is merged. Our systems power real-time voice, where an extra 100 milliseconds can change how a conversation feels. Behind that experience are GPU inference workloads for text-to-speech and speech recognition across AWS regions, alongside multi-tenant APIs, concurrency controls, billing and webhooks. We work with Python, TypeScript and Go on Kubernetes in AWS, supported by Redis, MongoDB-compatible stores, Postgres, ClickHouse, RabbitMQ and Temporal. Familiarity helps; understanding the mechanisms underneath matters more.
What you’ll own
- Define success before building. Establish measurable service-level objectives for customer-facing latency, availability and correctness.
- Write maintainable code. Build systems another engineer can understand, debug and operate without depending on you being available.
- Test beyond the happy path. Use unit, integration, load and fault-injection testing to validate behaviour under realistic conditions. Explain your coverage and its limitations in review.
- Ship safely. Own CI, deployments, rollbacks, schema migrations and infrastructure changes. When your work requires a Terraform change, you own that too.
- Operate what you build. Create useful dashboards, actionable alerts and runbooks. Participate in on-call, incident response and postmortems.
- Stay close to customer impact. When calls drop or requests fail, investigate directly, communicate clearly and drive the issue to resolution.
- Improve the system around the problem. Turn recurring incidents and manual debugging into better controls, automation and tooling.
The challenges you’ll help solve Our product works, and we’re strengthening the reliability practices that support its next stage of growth.
- Define SLOs for services that do not yet have clear reliability targets.
- Replace misleading health signals with monitoring that reflects whether customers can complete their tasks.
- Improve logging, health checks and alerting so failures are easier to detect and diagnose.
- Make testing and operational readiness a consistent part of delivery.
- Address existing reliability gaps alongside new product development.
You’ll fix problems you didn’t introduce and make decisions with incomplete information. You’ll also be expected to balance delivery speed with production readiness: surface risks early, propose practical trade-offs and follow through on commitments.
What we look for Strong engineering fundamentals and the ability to apply them to unfamiliar problems. We assess these directly through technical discussion and practical reasoning. You should be comfortable explaining and reasoning about:
- Processes and operating systems: Process creation, signals, file descriptors, namespaces, cgroups, PID 1 behaviour and CPU throttling.
- Memory: Virtual memory, page cache, available memory, swap, cgroup memory limits, out-of-memory behaviour and stalls that occur despite low CPU utilisation.
- Files and storage: Inodes, durability and fsync , disk-usage discrepancies, atomic rename, IOPS and throughput.
- Networking: TCP states, TIME_WAIT, connection and read timeouts, Nagle’s algorithm, delayed acknowledgements, DNS, TLS, NAT and the trade-offs of UDP for real-time media.
- Concurrency and distributed systems: Race conditions, locks, idempotency, at-least-once delivery, retries, backoff, jitter, backpressure, clocks and partial failures.
- Language runtimes: Event loops, blocking operations, garbage collection, the Python GIL, memory leaks and algorithmic costs at production scale.
- Data systems: Indexes, query plans, transaction isolation, row and column stores, and replication lag.
- Reliability: SLIs, SLOs, error budgets, latency percentiles, why percentiles cannot simply be averaged, and alerting on customer-visible symptoms.
We also value clear writing, the patience to read unfamiliar code and the habit of measuring before drawing conclusions. We evaluate demonstrated ability rather than years of experience, previous titles, employers, degrees, colleges, certifications or the number of frameworks on your résumé.
How we work
- Be honest about what you know. “I don’t know” is useful when followed by a clear approach to finding out.
- Share hypotheses early. Make your reasoning visible, invite scrutiny and update your view when the evidence changes.
- Take responsibility and improve the mechanism. Our postmortems focus on contributing causes and concrete changes that prevent recurrence.
- Start with the customer’s experience. A healthy pod does not mean a successful call. If the caller hears silence, we investigate it as a failure.
- Use evidence. Reach for traces, packet captures, profilers, query plans and load tests to understand what is happening.
- Challenge ideas respectfully. Question decisions—including those made by founders—with clear reasoning and evidence.
- Automate repeated work. When a problem keeps returning, build a better way to detect, diagnose or resolve it.
- Move with urgency. Make decisions at the right level, act on reversible steps and communicate blockers early. Use meetings when they help resolve a decision.
- Hold yourself to the standard you expect from others. Give direct, constructive feedback and receive it with the same openness.
What to expect This is a hands-on role with substantial accountability. It includes on-call responsibilities, occasional incidents outside regular hours, customer escalations and debugging across systems you may not have built. You’ll d
Sourced from the fund's portfolio job board — apply on the company's site.