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
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. What we're looking for 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.
Must-haves 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. Nice-to-haves Online handwriting, sketch, ink
or diagram recognition, in any script or notation. Geometric deep
learning, or graph neural networks applied to spatial data. Vector
graphics, CAD, GIS or trajectory modelling in an industrial
setting. Inference optimization and quantization. Published or
open-sourced work we can read. Spanish or Catalan. 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. 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.

📌 Senior Computer Vision Engineer (Cataluña)
🏢 Innovamat
📍 Cataluña