Software Engineer - Systems and Reliablity

**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,…