O que a vaga pede
Senior Software Engineer (Connected Device Fleet & Cloud Platform)
Type: Full-time, remote (strong overlap with US Central / AU business hours)
Level: Senior
About the role
We build and operate a large-scale platform for connected devices deployed across thousands of locations, plus the cloud services and web applications that drive them. It is a full-stack, high-scale environment: a runtime that has to work reliably on constrained hardware in the field, a cloud backend that publishes data to the fleet and ingests telemetry from it at scale, operator-facing web apps, and a healthy mix of modern and legacy code.
We are looking for a senior engineer who is comfortable across that whole surface: from a service on a device to a Lambda in the cloud to a maintenance change in a legacy UI, and who reasons well about the tradeoffs a system like this forces.
What you will work on
• Backend services on the device and in the cloud (content delivery, telemetry, APIs, auth).
• The on-device runtime and its packaging/delivery to the fleet.
• The pipeline that publishes data to devices and the pipeline that ingests telemetry back.
• Configuration and deployment across a large fleet.
• Operator-facing web applications, including legacy ones.
• Cross-cutting concerns: authentication and authorization, observability, and resilience.
Required (must-have)
Non-negotiable for day-one productivity.
• Strong Node.js + TypeScript for production services (event loop, streams, memory, native addons).
• Working comfort in PHP and legacy JavaScript (ES5 / CommonJS): parts of the codebase are exactly that. You change legacy code additively and do not need a rewrite to start.
• Bash / shell scripting and hand-written SQL (MySQL 8).
• Distributed-systems fundamentals: idempotency, retries with backoff, leader election, at-least-once vs exactly-once, backpressure.
• AWS core: Lambda + Serverless Framework, API Gateway, S3, IAM, SSM Parameter Store + Secrets Manager, CloudWatch, and the AWS SDK, with least-privilege and cold-start reasoning.
• Backend: Fastify and/or Express, WebSockets (ws and socket.io), dependency injection, and a contract-first mindset (JSON:API or similar).
• Auth: Auth0, OIDC, and JWT / JWKS (you know decoding is not verifying).
• Data: MySQL 8 and MongoDB.
• Infra & delivery: Docker + Docker Compose, nginx + TLS, Debian packaging, cron, systemd, Git, GitLab CI.
• Testing: Jest, with the discipline to keep core logic in pure, injectable functions.
• Senior communication: design docs / RFCs, and the judgment to know when a decision needs one.
Nice to have, or the strength we accept instead
We would rather hire the aptitude than the exact tool. If you do not have the item on the left, the signal on the right is what we look for instead, and it is what we will probe in the interview. A strong senior who can transfer one of these is preferred over someone who lists the tool but cannot reason about its tradeoffs.
- Cloud-scale streaming: Kinesis + Firehose versus Any high-throughput streaming/eventing at scale (Kafka, SQS, Pub/Sub) with ordering, backpressure and idempotency reasoning
- DynamoDB, SQS FIFO versus Any managed NoSQL plus a queue, with ordering-vs-throughput and dedup/idempotency reasoning
- Memcached, Elasticsearch versus Any cache plus any search/analytics store, with cache-invalidation and cold-cache/degradation reasoning
- API Gateway (REST, HTTP, WebSocket) versus Any managed API/gateway layer, and reasoning about connection-based vs request-based APIs
- Frontend: AngularJS 1.x + Angular Material, Angular 10 + RxJS, React 18 + Vite, Module Federation, SCSS versus Strong component-based UI in any framework you can transfer; for the legacy stacks, demonstrated ability to be productive in an unfamiliar or legacy framework
- nginx njs scripting versus Comfort reading and changing edge/proxy config, and judgment about what logic belongs at the edge vs the app
- Single-exe packaging (pkg) versus Any experience shipping a runtime to constrained targets: cross-compiling, native dependencies, static or sidecar packaging
- Deep Debian packaging + systemd versus General Linux service lifecycle, plus willingness to own packaging end to end
- Python versus Any strong second backend/scripting language; we assess general language transfer, not the syntax
- ffmpeg versus Any media processing, or clear reasoning about where transcode/thumbnail belongs (cloud on upload vs device on play)
- New Relic versus Any APM (Datadog, OpenTelemetry, Grafana) and golden-signals thinking
- ECS / Fargate, EC2 / ELB / Route 53 / ACM / RDS, CloudFormation versus Any container orchestration plus any IaC (Terraform or CloudFormation)
- Lambda@Edge + CloudFront versus Any CDN or edge-compute experience
- Git LFS versus Any experience managing large binary artifacts in version control or an artifact registry
- On-device / IoT / hardware integration versus Any hardware-integration or telemetry-at-scale work, or systems where “reported” and “true” can diverge
What we look for in a senior
• Names failure modes and blast radius unprompted, not only when asked.
• Compares two approaches and can say when each is the wrong one, rather than reciting a definition.
• Debugs by separating “what the system reports” from “what is actually true,” and asks for the data.
• Reasons about scale with shards, queues, and percentiles, not just correctness.
• Treats legacy with a strangler mindset and additive change, not a rewrite reflex.
Problems you will help us solve
• Telling a device that is genuinely working from one that only claims to be. A stale “healthy” signal is worse than an honest error.
• Getting a runtime to place and render output correctly on cheap, quirky hardware sitting in a store.
• Showing the right thing at the right time, the way the customer scheduled it.
• Moving telemetry off a large fleet reliably, without melting the ingest tier when everyone reports at once.
• Keeping the devices in one location agreed on a single primary, including while things are failing.
• Shipping a runtime with native dependencies to hardware that has no build toolchain of its own.
How we work
Remote, async-friendly, with real overlap hours. GitLab for code and CI, design-doc-driven decisions, and a culture of code reuse across teams. We test against real hardware where it matters, because some behavior only appears on device.