Software Engineer

The job

You own a service or a slice of the product, end to end. No QA team catches your bugs, no DevOps team deploys your code, and no SRE team gets paged for it. You do all three.

• Define it. Write the customer-facing SLO before the first line of code: latency, availability and correctness, as numbers.
• Build it. Write code someone else can debug at 3 a.m. without you.
• Test it. Unit, integration, load, and fault injection. You decide what "tested" means and defend it in review.
• Ship it. CI, deploys, rollbacks, schema migrations, infrastructure as code. If your change needs a Terraform diff, you write the diff.
• Run it. Dashboards, alerts on customer pain rather than CPU, on-call, postmortems.
• Answer for it. When a customer's calls drop, you are in the thread with the logs, not waiting for a ticket.

The work is real-time voice, where every extra 100 ms is audible to the caller. Behind it: GPU inference for text-to-speech and speech recognition across AWS regions, and multi-tenant APIs with concurrency limits, billing and webhooks that customers run their businesses on.

We use Python, TypeScript and Go on Kubernetes in AWS, with Redis, MongoDB-compatible stores, Postgres, ClickHouse, RabbitMQ and Temporal. You don't need to have used any of them. You need to understand what they do underneath.

Where we are

The product works. Its reliability could be much better, and we are hiring to improve it.

• Most services have no written SLO, so nobody can say whether they are meeting one.
• We have had dashboards report green while customers received nothing, because we measured implementation instead of outcomes.
• Failures hide in logs at the wrong level, behind health checks that pass, and inside alarms that are noisy.
• Testing and operations were treated as other people's jobs. This role ends that.

You will fix things you did not break. You are expected to say no to shipping what isn't ready, including your own work. You are also expected to deliver on time. Go figure!

What we look for

Depth in the layers everything else runs on. We test this directly on the technical call with Rhea; nothing on paper substitutes for it.

Processes and the OS

fork and exec, signals, file descriptors, what a container is (namespaces and cgroups), why PID 1 is special, CPU throttling under a quota

Memory

virtual memory, the page cache, what "available" memory means, swap, the OOM killer inside a cgroup, why a box stalls at low CPU

Files and storage

inodes, what fsync does and does not guarantee, why df and du disagree, atomic rename, IOPS versus throughput

Networking

TCP states, TIME_WAIT, connect versus read timeouts, Nagle and delayed ACK, DNS resolution and caching, TLS handshake cost, NAT, why voice runs over UDP

Concurrency and distributed systems

races and locks, idempotency, at-least-once delivery, retries with backoff and jitter, backpressure, clocks, partial failure

Runtimes

event loops and what blocks them, garbage-collection pauses, the GIL, leaks, the real cost of an algorithm at scale

Data

indexes and query plans, isolation levels, row versus column stores, replication lag

Reliability

SLIs, SLOs and error budgets, percentiles (and why they cannot be averaged), alerting on symptoms

We also look for clear writing, the habit of reading code you didn't write, and measuring before guessing.

We ignore years of experience, titles, employers, degrees, colleges, certifications and the list of frameworks on your resume.

How we work

• Say "I don't know." Then say how you would find out. Bluffing ends an interview here faster than any wrong answer.
• Be wrong in public, early. Post the half-formed hypothesis in the incident channel. Corrected in five minutes beats right in five hours.
• Own the mistake, fix the mechanism. Postmortems name causes, not people, and end with a change that ships.
• The customer's experience is the metric. Not pod status, not CPU. If the caller heard silence, it was down.
• Measure. strace, tcpdump, perf, EXPLAIN, a load test. Then form the opinion.
• Disagree with anyone, founders included, with evidence. Expect the same back.
• Build the tool that's missing. If you debug the same thing twice, the third time is a script.
• Raise the bar on yourself first, then in review.

Not for you if

• You want a spec handed to you and someone else to test, deploy and watch it.
• You consider your work done at merge.
• You know many tools and few mechanisms.
• Being corrected by someone with less experience bothers you.
• You need a title, a ladder or reports to feel progress.
• Your ego isn't low.
• You'd rather cover up a screw-up than admit it was stupid.
• You want a calm job. This one has pages at bad hours, customers who are angry for good reasons, and other people's bugs.
• You are slow. We move fast, and we need you to run faster.
• You'd rather call a meeting than act. We have an action bias.

How to apply

No resume, no cover letter, no screen on paper: everyone who applies gets the intro call. Calls are in English, in your browser, with Rhea, Smallest's AI interviewer. Rhea runs on our own voice products, so you are testing them too. Calls are recorded, and an engineer reads every transcript before any decision.

1. Apply

   2 minutes · on this page

   Your name, email and phone, and four consents. Then enter the code we email you.

2. Intro call

   5 to 10 minutes · with Rhea

   The role, what to explore, and your questions. Nothing on it is assessed.

3. Product trial

   2–3 focused hours, 24 at most · within 7 days of the intro call, before or after the technical call

   Sign up for Smallest with the same email and use Atoms and Waves. Then write a short engineering QA report on one area: the APIs, the Atoms product, developer experience or reliability. Judge the engineering, not the voices: does it do what the docs say, fail clearly and recover?

   New accounts get $10 of credit; once it runs out, ask for one more $10 on your page.

   The trial is needed before the paid build. Trying the product before the technical call helps: the call starts from what you found.

4. Technical call

   About 40 minutes · with Rhea · whenever you are ready within the same 7 days · one attempt

   It starts from what you found in the product, if you tried it first, then goes into fundamentals, a production incident you debug out loud, and an estimate. Think out loud: how you reason is what we assess, and "I don't know" is a good answer when it is true.

5. Build and run

   2 days, paid · with an engineer

   A paid work trial. Build a small service, set its SLO and ship it. On day two we break it while you hold the pager.

6. Founders

   About an hour · with Sudarshan Kamath (CEO) and Akshat Mandloi (CTO), the co-founders

   We talk.

7. HR round

   With Hetvi Kidecha, HR

   Pay, the offer, your start date and anything left open.

Questions along the way? From the end of the intro call, you can call Rhea from your page about the role, the process or the product, up to 15 minutes at a time. These calls are never assessed. Tell Rhea anything, a concern, feedback or a request, and it reaches Hetvi Kidecha, who looks after hiring on the HR side, and the hiring team.