Skip to content
Esc
Internships in Canada
New-grad roles in Canada
Remote roles
Roles that show pay
Postings at high ghost risk
PayWhat student tech roles in Canada pay
Check a linkPaste a posting to see its real age and ghost risk
JobsEvery open tech role
CompaniesWho fills fastest, who leaves postings up
Hiring calendarWhen employers open intern and new-grad roles
Skills gapWhat postings ask for that you don't have
Your resumeScore and fixes
Your matchesOpen roles ranked by your resume
ApplicationsSaved, applied, interviewing, offers
SettingsTheme, text size, motion
How it works

↑ ↓ to move, Enter to open? every shortcut

Keyboard shortcuts

CtrlKor/
Search employers, postings and pages
JorK
Next or previous posting in a list
O
Open the posting's page
Enter
Open it in the preview, on wide screens
S
Save or unsave it
?
This list
Esc
Close
Smallest

Software Engineer - Systems and Reliablity

  • Seen live on Smallest's site 2 days ago
  • Mid level
Pay
Not stated
Location
Bengaluru
Open for
12+ days
First seen
Oct 23, 2026
Apply on Smallest's site (opens in a new tab)

Posting record

No flags

Open 12+ days

The posting's record, oldest first
  1. Smallest's site dates the posting
  2. Ghostless first sees this listing
  3. Last checked: still up
How we know

It hasn't been reposted, listed twice, or left up unusually long, and the posting doesn't say it's a talent pool.

Ghostless records the day it first sees a posting, so a repost can't reset its age. This one was already up when Ghostless started tracking Smallest, so its true age is longer.

Last checked Nov 2, 2026.

How well do you match?

See how much of this posting your resume shows, and what it's missing.

Upload your resume

What the posting discloses

Not stated: Pay, real vacancy, AI screening.

Why these three

Ontario requires postings from employers with 25 or more staff to state the pay, whether the vacancy exists, and whether AI screens applicants.

Some employers add pay only on their own site. Check the original posting before you rule it out.

Skills mentioned

About the role

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 do well here if you enjoy understanding how systems work, acting quickly and staying with a problem until it is resolved.

This role may not suit you if you prefer narrowly defined implementation tasks, consider your responsibility complete at merge, or expect testing and production operations to sit entirely with another team.

Why join Smallest.ai

Build systems where engineering decisions are audible in the customer experience. You’ll work across real-time voice, GPU inference and distributed infrastructure, with the opportunity to improve both the product and how we build and operate it.

Your impact will show up in faster responses, fewer failed calls, safer releases and systems the whole team can trust.

Something wrong with this posting?