Senior Computer Vision Engineer

Innovamat is an educational organization focused on mathematics learning. Our mission is to improve the way the subject is taught, by offering resources, training and research to the educational community. Since we were founded in Barcelona in 2017, we have partnered with more than 27,000 teachers in over 2,800 schools across nine countries, reaching more than 600,000 students.

Within Innovamat, Mathboard AI is the technology that reads what students write by hand. When a student solves a problem on a digital board, we receive the pen strokes themselves — not a photograph, not typed text. Our models have to work out which strokes belong together and what each group means, so the student can be understood and helped in the moment.

We are looking for the person who takes those models further. It is a multiple-instance detection problem on handwritten input, solved directly on the pen strokes rather than on a rendered image — a formulation with no off-the-shelf solution to copy and no public benchmark that stands in for the real thing. The work is genuine research engineering: understand where the model falls short, form a hypothesis about why, build it, and find out honestly whether it worked.

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.

What you'll do

Own the models

• 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.

Make the gains real ones

• 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.

Get it into classrooms

• 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.

Choose what is worth building next

• Work closely with the person who owns