About Mateo Briosso.

I live in Montevideo, on the Uruguayan coast. Every company in my history is either in this city or on the other end of a video call, and for the last few years the calls have mostly been with the United States. I contract with US clients through a Wyoming LLC. UTC-3 means my afternoon is somebody's morning in New York and Chicago, which is the only logistics detail anyone ever actually asks about.

I studied computer science at Universidad ORT Uruguay, first an associate degree and then the BSc, and finished in 2017. My first job was at Abstracta, writing Selenium in Java on a team that worked test-first. I expected to spend a year there and move into building product.

What happened instead is that I found the part of the work I was actually good at. Somebody has to build the thing that tells five hundred people whether the release is safe, and that thing is a piece of software with an architecture, a concurrency problem and a deployment story. It is a harder engineering problem than most of the features it checks. Nine years later I have built four of them from scratch, in Java, TypeScript, JavaScript and Python, for web, for mobile, and for APIs.

Between then and now: Oktana, Globant, Altimetrik, DataArt, OrangeLoops, and since 2024 a US insurance company where I run two JavaScript frameworks and led the migration that produced them. At OrangeLoops I was QA Lead with two junior engineers reporting to me. At Globant I was the person the dev team asked about automation, which meant reviewing a lot of other people's code and having opinions in writing. The full history is here.

A failure should be a diagnosis. A red test that says "expected true, got false" costs somebody an hour. A red test that arrives with the console log, the request, and the screenshot costs them four minutes. Most of the engineering in a good suite is spent on what happens after something goes wrong, not on the assertion itself.

Flakiness is a trust problem, not a technical one. The moment a team learns that red sometimes means nothing, the suite is finished, whatever the coverage number says. I would rather have forty tests everyone believes than four hundred nobody reads.

Write for the person who inherits it. Every framework I have built was eventually handed to someone else. Someone I have never met has to add a test to it on a Tuesday under deadline, and whether they can is the actual measure of whether the design was any good. That is also why I care about code review more than most people expect a QA engineer to.

Correctness is a property of the whole system. The interesting bugs are never in one function. They are in the seam between two services, or in the browser you did not run on, or in the third concurrent user. That is why the work moved me toward infrastructure, parallel execution and pipelines rather than deeper into any one framework.

Given the choice between a status meeting and a short written update, I will send the update, because it is searchable in March.

I ask what broke last, first. It is the fastest way to find out where a system is actually weak, and it tends to be a more honest conversation than a feature list.

I mentor when there is someone to mentor. Two juniors at OrangeLoops, code review for peer engineers at Globant. The best version of this job is the one where the team ends up able to do it without me, and I have never found that to be bad for job security.

I say when something is out of scope for me. I have spent nine years on correctness, concurrency and delivery pipelines. I have not spent them on design systems or data science, and I will tell you that before you find out.

If you are hiring, the full history is on the experience page. If you want the productised version of what I do, that is on the work page.