What are the responsibilities and job description for the Software Engineer, Models position at Meter?
Why this role exists
Network engineers carry the most valuable signal in the world in their heads, and it disappears the moment they close a ticket.
Your job is to build the system that captures that signal so that our models can learn to think like network engineers.
If you get this right, Meter can manage thousands of customers’ networks autonomously, without adding a single engineer.
The problem you’re walking into
LLMs are good at code because of their access to Git. Commit messages explain why a change was made, PR threads capture expert disagreement, issue trackers record dead ends and eventual fixes. Models trained on that corpus of data don’t just pattern-match, they’ve seen millions of examples of human reasoning through problems.
Network engineering has none of this. When a network engineer looks at a set of device stats and figures out it’s upstream packet loss — not a hardware failure, not a misconfiguration, specifically upstream packet loss — that reasoning lives in their head. Never in a place a model can learn from.
You will build the Git and Github for network engineering. A structured, queryable record of what the network looked like, what the expert notice, and why they made the call they made.
What you will ship
First 30 days
Sit with our network engineers and watch how they work. Don’t touch code yet. Understand what a great diagnostic reasoning record actually looks like and what data you’ll need to build one. Map the existing landscape: telemetry in ClickHouse, configs in Postgres, support history in Salesforce.
60 days in
Ship a working v1 of the annotation interface. Network engineers should be able to open a historical support ticket, see what the network looked like at the time of the incident, and log their diagnostic reasoning against it. It doesn’t have to be elegant, it has to be useful enough for engineers to want to use it.
90 days in
Our network engineers are generating training data independently without engineering support. The first model benchmarks built from the pipeline are running and you can point to a number knowing the model improved because of what you shipped.
Tech Stack
TypeScript, React, Go, GraphQL, Kafka, Postgres.
Who you’ll work with
Our co-founder and CEO will lead the product roadmap.
In addition to your customers, network engineers, you’ll partner closely with two research engineers who have deep ML backgrounds and a clear picture of what training data needs to look like. They’re excited to have a partner in building the app.
Measuring success
You’ve built backend systems end-to-end and made real architectural decisions with real consequences. You have opinions about data storage that come from having made the wrong decisions.
You have deep customer empathy. You’ll spend your first weeks learning how network engineers think and work. This knowledge will shape your future decisions.
You care about people using the tools you built for them. Network engineer tool adoption and satisfaction leads to critical training data, model improvement, and eventually autonomous networks.
Network engineers carry the most valuable signal in the world in their heads, and it disappears the moment they close a ticket.
Your job is to build the system that captures that signal so that our models can learn to think like network engineers.
If you get this right, Meter can manage thousands of customers’ networks autonomously, without adding a single engineer.
The problem you’re walking into
LLMs are good at code because of their access to Git. Commit messages explain why a change was made, PR threads capture expert disagreement, issue trackers record dead ends and eventual fixes. Models trained on that corpus of data don’t just pattern-match, they’ve seen millions of examples of human reasoning through problems.
Network engineering has none of this. When a network engineer looks at a set of device stats and figures out it’s upstream packet loss — not a hardware failure, not a misconfiguration, specifically upstream packet loss — that reasoning lives in their head. Never in a place a model can learn from.
You will build the Git and Github for network engineering. A structured, queryable record of what the network looked like, what the expert notice, and why they made the call they made.
What you will ship
First 30 days
Sit with our network engineers and watch how they work. Don’t touch code yet. Understand what a great diagnostic reasoning record actually looks like and what data you’ll need to build one. Map the existing landscape: telemetry in ClickHouse, configs in Postgres, support history in Salesforce.
60 days in
Ship a working v1 of the annotation interface. Network engineers should be able to open a historical support ticket, see what the network looked like at the time of the incident, and log their diagnostic reasoning against it. It doesn’t have to be elegant, it has to be useful enough for engineers to want to use it.
90 days in
Our network engineers are generating training data independently without engineering support. The first model benchmarks built from the pipeline are running and you can point to a number knowing the model improved because of what you shipped.
Tech Stack
TypeScript, React, Go, GraphQL, Kafka, Postgres.
Who you’ll work with
Our co-founder and CEO will lead the product roadmap.
In addition to your customers, network engineers, you’ll partner closely with two research engineers who have deep ML backgrounds and a clear picture of what training data needs to look like. They’re excited to have a partner in building the app.
Measuring success
- Within 90 days, Network engineers are generating training data independently, without pinging you
- We have a large set of high-quality annotated cases in the pipeline
- Model benchmark scores are moving in the right direction because of the data this pipeline produced
You’ve built backend systems end-to-end and made real architectural decisions with real consequences. You have opinions about data storage that come from having made the wrong decisions.
You have deep customer empathy. You’ll spend your first weeks learning how network engineers think and work. This knowledge will shape your future decisions.
You care about people using the tools you built for them. Network engineer tool adoption and satisfaction leads to critical training data, model improvement, and eventually autonomous networks.