|

The conventional engineering interview measures the wrong things. It tests the ability to solve contrived puzzles under artificial pressure. We evaluate something different: whether a person can reason about systems, ship production code with discipline, and leverage AI tools as a force multiplier.

What we evaluate

We look first for systems thinking — the capacity to reason about how components interact across a full stack and to anticipate the second-order effects of a design decision. We are building a platform, not a feature, and that requires people who think in systems rather than in isolation. We look for shipping velocity: the disciplined ability to scope tightly, build cleanly, and deploy confidently. Show us your commit history. It reveals more than any interview answer ever could.

We require AI fluency. Every engineer at Nexma works with AI pair programming daily, and if you have not used these tools extensively, you will begin at a disadvantage. We want people who already regard AI as infrastructure, not as novelty. And we need TypeScript depth, because our entire stack — monorepo, server-side rendering, client applications — is TypeScript. We need people who think in types, not people who struggle against them.

The process

There are no multi-round gauntlets. There are no take-home projects designed to consume a weekend. You speak with us about what you have built. You pair with us on a real problem drawn from our codebase. You ship something small. The entire process takes days, not weeks, because we respect the time of serious engineers and because protracted hiring processes select for people with the most free time, not the most talent.

What matters less

Algorithm puzzles measure puzzle-solving ability, not engineering judgment. We do not use them. We care about whether you can build production systems that real users depend on — not whether you can invert a binary tree under time pressure. The distinction matters because we have found, repeatedly, that the skills tested by conventional interviews bear almost no relationship to the skills required to build consequential software.