Senior Computer Vision Engineer, Innovamat

• We are looking for depth rather than breadth. The bar is someone who could plausibly take a problem of this kind as far as anyone has taken it
• Real depth in multiple-instance detection or instance segmentation. You have built models that find a variable, unknown number of objects in a single input and attribute each part of that input to exactly one of them — including how predictions get matched to ground truth during training, and what the resulting metrics do and don't tell you
• Experience with non-rasterized input, or a clear grasp of what changes without a pixel grid. Strokes, polylines, trajectories, point clouds, graphs, vector graphics, CAD geometry or sensor traces — anywhere the input is a set of geometric primitives rather than an image. If your instance-detection work has been on pixels, we will want to talk about how you would approach it without them
• Attention-based architectures over sets and graphs, and a feel for how spatial and relational structure gets encoded into a model — including the instinct for when a model simply cannot see something you assumed it could
• Serious experience training deep models in PyTorch — not calling a training API, but owning the loop: schedules, numerical stability, distributed runs, and the debugging of a model that trains happily without getting better
• The experimental discipline to run fair comparisons, resist reading noise as signal, and say plainly when a result is inside the band
• Evidence you can take a model into production — export, latency, determinism, and a rollback path
• The ability to read the literature critically: reproduce what is useful, and tell a genuine advance apart from a benchmark artifact

Desirable

• Take architectural responsibility for the models that read handwriting — how the input is represented, how instances are proposed and assigned, how the models are trained, and how they get better
• Design the changes you believe will move the hard cases, implement them properly, and run them at a scale where the answer is trustworthy
• Keep a fair challenger alive. Whatever we are running is the incumbent, not a commitment, and part of the job is knowing when a different formulation would beat it
• Run controlled comparisons with success criteria agreed before the run, so a result means what it appears to mean
• Look past the headline number at which kinds of page improved and which regressed, and judge whether the trade was worth making
• Replicate anything you intend to ship, and report the attempts that went nowhere as clearly as the ones that worked
• Take a model through to something that answers fast enough on ordinary school hardware, not only on a training GPU
• Guarantee that what we deploy behaves like what you evaluated, and that we can roll it back the moment it doesn't
• Watch what it does on real student work once it is live, and turn what you see there into the next thing you try
• Work closely with the person who owns our datasets and evaluation, and be specific with them about what would actually change a result
• Judge honestly when the limit is the model, when it is the data, and when the task itself is genuinely ambiguous
• This is not an LLM or prompt-engineering role, and it is not a data-pipeline role — a separate opening covers datasets and evaluation. It is also not a pure research position: what you build is expected to reach students
• The problem you would be working on:
• A student fills a page. On it there might be four separate calculations, two arrows linking one result to the next, a small diagram, a crossed-out attempt, and a few marks that belong to nothing at all
• The model has to find every one of those objects, say what kind each is, and say exactly which pen strokes make it up — all at once, with no fixed number of objects and no guarantee that any two pages look alike
• So it is multiple-instance detection, but the primitives are strokes rather than pixels
• One object is made of a variable number of strokes; strokes cross and interleave; two different objects routinely occupy the same region of the page, so the question is never where an object roughly is but which specific marks constitute it
• And a page counts as correct only when the entire reading is right — every object found, every kind correct, every stroke attributed. There is no partial credit
• It is a computer vision role in that it is about visual structure and spatial reasoning
• It is not one in the sense of convolutions over photographs, and the difference is worth being explicit about before you apply
• Little of the pretrained stack transfers. The large vision backbones everyone builds on assume a pixel grid. Here, how the input is represented is a design decision you own rather than a default you inherit
• Relationships carry the signal. What decides whether two strokes belong together is proximity, relative scale, alignment, and what else is on the page — not appearance in isolation
• The straightforward gains are already taken. Progress comes from careful diagnosis and a good hit rate on non-obvious ideas, and from getting real information out of the attempts that fail — which will be many of them
• It has to run in a classroom. The answer has to arrive while a child is still looking at the screen, on whatever device the school happens to own
• How we work:
• You would join a small technical team with direct access to the people making product decisions, and an unusual amount of ownership over the direction of the model itself
• We write things down. Every experiment, including the ones that fail, is recorded where the next person can find it
• And we hold two rules seriously: results are judged against criteria agreed before the run, and no number is quoted before its data has been checked
• Both exist because we have been caught out without them
• You would have the GPUs you need. Compute has not been our constraint — judgement about what to spend it on has