Senior .NET Engineer, Camera Systems

The short version

There are 2,500+ machines in the field with four network cameras inside each one. That's roughly 10,000 cameras today, and the program is on track to multiply several times over. Our enterprise customer is a household-name global brand, and VendNovation has been the lead software provider since day one.

You'd own everything between those cameras and the software running in the machines.

This is a dedicated seat for a specialist. Camera and streaming work at this depth is its own discipline, not something a strong generalist picks up on the side. We'd rather hire someone who already lives in this world than keep learning it the slow way, and whoever takes the role owns the area outright.

What you'd actually be dealing with

• ~10,000 IP cameras in unattended machines, each behind a Windows PC, spread across the country.
• A camera manufacturer that swaps firmware without warning. No docs, no release notes. A single silent change can take hundreds of cameras offline at once.
• No vendor hand-holding. Answers don't come from the manufacturer. A lot of this job is working out camera behavior from the outside, with packet captures, logs, and good instincts.
• Multiple firmware versions live in the field at the same time. Occasionally several inside one machine.
• A GStreamer pipeline (we moved off FFmpeg) wrapped in a worker-process architecture built to keep streams alive through failures.
• A machine-vision partner consuming our streams over a proprietary protocol. When they don't get every camera view they asked for, that's ours to fix.

If that list reads as a nightmare, this isn't your role. If you read it and started forming theories, keep going.

Why engineers take this job

• The work is rare. ONVIF at fleet scale, on Windows, on unattended hardware, feeding a machine-vision system. There isn't much else like it, and the expertise compounds.
• Real ownership. Nobody is going to hand you a spec. You'd own the camera and streaming area end to end, and you'd be the person who knows it best.
• It's bound to hardware. A $25,000 machine, physical testing, edge cases that only appear at 10,000 units. This is not a codebase anyone replaces with a clever afternoon of prompting.
• Stability without bureaucracy. 25 years old, about 50 people. Large enough that you're not watching for a missed payroll while startups fold around you. Small enough that there's no approval chain to fight.
• Remote before it was a perk, still remote. No return-to-office plan, no hybrid schedule, no three days downtown.
• Modern tooling, used seriously. The client team works with Claude and agentic tooling as a normal part of engineering. If you already use these tools for substantive work, reading unfamiliar C++, chasing protocol behavior, building test coverage, you'll have room to run.

What you'll own

• Camera discovery, authentication, configuration, and control over ONVIF, across manufacturers and firmware that disagree about what the standard means.
• The GStreamer-based capture and streaming pipeline: acquisition, delivery, lifecycle, recovery.
• Stream reliability for the machine-vision partner. Every requested view, every time, through restarts, disconnects, timeouts, and abandoned consumers.
• Diagnostics and telemetry that make camera problems visible: what firmware is on which camera, what failed, and why.
• Hardware-assisted tests and compatibility documentation, so "will this camera model work" becomes a question with a real answer.
• Being the technical counterpart to the partner's engineering team and clearing camera-related blockers before they escalate.

What you'll bring

• 7+ years building production software in C# and .NET.
• Deep hands-on ONVIF: discovery, media services, profiles, authentication, capabilities, and all the ways vendor implementations deviate from the spec.
• Production experience with RTSP and network video streams.
• GStreamer experience, or enough camera depth that you can read the C++ and work out what it's doing.
• Strong instincts for stream lifecycle: concurrency, reconnection, resource cleanup, backpressure, failure recovery, long-running stability.
• A track record of debugging across boundaries, including application code, network, OS, and third-party firmware, and the intermittent failures nobody else can reproduce.
• Comfort working directly with an external engineering partner, keeping things moving instead of arguing about whose component broke.
• Real use of Claude or similar agentic tools for substantive engineering work, plus the judgment to evaluate what they produce.

Nice to have: Wireshark and packet analysis; FFmpeg; WS-Discovery, SOAP, and digest authentication; multi-vendor camera integration; Windows edge, kiosk, or unattended deployments; device compatibility matrices; network topology including VLANs, multicast, DHCP, and NAT.

What success looks like

First 3 months

• You can reproduce the top failure modes on demand, in the lab and against real field data.
• You're the camera and streaming counterpart to the machine-vision partner, and they know to call you.
• The firmware compatibility problems in front of us have a diagnosis and a path forward.
• Baseline diagnostics exist. We can finally answer what firmware is running on which camera in the field.

By 6 months

• Stream loss, crash, and reconnect-failure rates are measurably down, proven with numbers we didn't have before you got here.
• A compatibility matrix exists: supported models, firmware versions, known limitations, required configuration.
• Hardware-assisted tests cover discovery, concurrent requests, stream handoff, reconnection, and process recovery.
• Camera issues are no longer a standing item on the partner's blocker list.

By 12 months

• The streaming subsystem is stable, observable, and scalable enough that fleet growth doesn't drag ticket volume up with it.
• Evaluating a new camera model takes days instead of a quarter, and the verdict holds up.
• Firmware surprises get caught by our tooling before the customer notices them.
• You're the person the company asks before any camera decision gets made, and that knowledge lives in docs and tests, not only in your head.

Interview Process

Three conversations: the hiring lead, our most senior engineer on the client team, and our senior PM. Expect a deep technical dive on cameras and streaming.