Computer Vision Engineer

We turn technical documents into numbers customers can trust and verify.

You'll own the part of the system that reads and measures those documents. Some files have real structure (vector paths, layers, transforms). Others are just pixels. You'll handle both. Read the structure when it exists. Build models when it doesn't.

Everything ships to production on CPU, within a few GB of memory, under a strict time limit.

What you'll do

Document and geometric CV

• Parse vector files at the primitive level (paths, strokes, fills, transforms, layers) and rebuild what a person actually sees

• Filter out overlays and annotations that shouldn't be measured

• Work with lines, centrelines, skeletons, contours, topology, broken and duplicate geometry

• Match labels to objects and check if they agree with the geometry

• Get coordinates and units right across rotations, nested transforms, and multi-scale pages

• Extract tables, legends, and title blocks, including ones that are drawn, not encoded

Models

• Build OCR for cases where standard OCR fails: stroke fonts, rotated text, dense pages

• Detect small, repetitive, rotated symbols on flattened pages

• Extract hand-added markup

• Classify line styles, weights, dashes, and hatching

• Generate your own training data with synthetic examples and programmatic labelling

• Evaluate honestly on held-out data, especially on CPU

Engineering

• Define success and measure against real ground truth before changing anything

• Don't break what already works

• Treat speed and memory as core requirements

• Build visual debugging tools so people can see what's right and wrong

• Write clean Python and ship your own validated work to production

• Explain your decisions, including when you changed your mind

Nice to have

• Vector graphics, CAD, GIS, or floor plan experience

• Using VLMs as a cross-check or data generator, not the main signal

• Optimising models for CPU inference

• TypeScript or another language alongside Python

• Background in construction, estimating, engineering, or anywhere a wrong number costs more than "we don't know"

• Building your own ground truth from scratch

How we work

• Measure first. Size the problem before solving it.

• Kill your own ideas. Disprove four approaches in a week rather than defend one for a month.

• Models aren't always the answer. Sometimes you just read the file properly.

• Talk to practitioners. Some of our hardest problems were solved by asking them.

• Be honest about uncertainty. A wrong number is worse than "we don't know."

• Own the problem. "This document only reads 30% of what it should." Find out why and fix it.

#ComputerVision #MachineLearning #Hiring #Python #OCR #CAD