What we test for
Typical work
- APIs other teams build on, versioned so a change does not break them
- Integrations with payment, identity and third-party services, with failure handled
- Performance work: the slow query, the N+1, the endpoint that times out at peak
- Moving a monolith forward one piece at a time instead of rewriting it
The coding test
Build a small service with an endpoint, a database and a call to a slow third-party API. Then we make that API fail half the time and ask what the user sees. Scored on timeouts, retries, idempotency and the tests that prove them, not on how many endpoints they wrote.
Inside Back-End
The ones people search for by name get a page of their own, with their own coding test and interview questions.
Java
Spring Boot, Hibernate, JUnit, Maven. APIs, migrations and performance work.
See the page →Spring Boot
Boot 3 services, Boot 2 upgrades, and auto-configuration they can actually explain.
See the page →Node.js
TypeScript services, REST and event-driven APIs, testing that runs in CI.
See the page →NestJS
Modules that keep a TypeScript service readable past the point routes can hold it.
See the page →GraphQL
A schema that survives three teams, resolvers with a data loader, and a cost limit that keeps one query from taking the service down.
See the page →Python
Backends, data pipelines and integrations with tests and type hints.
See the page →Django
The ORM, the admin and DRF, on databases too big to lock while you migrate.
See the page →FastAPI
Async APIs with schemas that document themselves, and nothing blocking the loop.
See the page →PHP
Platforms you need to extend, upgrade or modernize without a rewrite.
See the page →Laravel
Features on an app that already earns money, with queues that are safe to retry.
See the page →Symfony
Explicit wiring, Doctrine that stays fast, and domain rules that outlive a major version.
See the page →.NET and C#
Enterprise services in C#, and the migration off .NET Framework that keeps getting postponed.
See the page →ASP.NET Core
The web layer: minimal APIs or controllers, middleware in an order you can explain, and auth that stays out of the handlers.
See the page →Go
Services that stay up, with an owner and a stop for every goroutine.
See the page →Rust
The parts where a crash or a pause is not an option, from someone who argues with the borrow checker and wins.
See the page →Ruby on Rails
Rails applications that already earn money: upgrades, the parts that outgrew the framework, and a suite that still runs.
See the page →Elixir and Phoenix
A lot of connections at once, supervision that restarts the right thing, and LiveView where it replaces a front end.
See the page →Five interview questions you can reuse
We use questions like these in our soft-skills and technical rounds. Steal them for your own interviews.
A request that used to take 50 ms now takes two seconds. Where do you start?
A strong answer covers: With a trace, not a hunch: where the time goes between the handler, the database and anything called over the network. Most of the time it is a query whose plan changed as the table grew, or a call that now happens once per row. The answer to listen for is how they would prove the cause before changing anything.
How do you make an endpoint safe to call twice?
A strong answer covers: An idempotency key from the client, stored with the result, so a retry returns the first answer instead of doing the work again. Payments and anything that sends an email need it first. A senior will also ask what the client does when it never hears back, because that is when the second call happens.
When does a cache make things worse?
A strong answer covers: When nobody can say how it gets invalidated, or when it hides a slow query that will come back the day the cache is cold. A good answer names the key, the lifetime and what the user sees while it is stale. Caching a thing that is cheap to compute is just a second place to be wrong.
How do you change a database schema without downtime?
A strong answer covers: In steps the running code survives: add the new column, write to both, backfill, move reads, then drop the old one in a later release. A migration that locks a large table at peak is the usual outage. Listen for the order of the steps and for when they would refuse to do it in one deploy.
When would you split a service out of a monolith?
A strong answer covers: When one part needs to deploy, scale or fail on its own, and the boundary is already clean in the code. Splitting first and finding the boundary later gives you a distributed monolith with network calls in place of function calls. Being able to argue for not splitting is the senior answer.
One invoice a month.
The shortlist is free. Pick the contract that suits you: monthly, six months or twelve.
What every seat includes
- Contracts, payroll and compliance handled
- Vetting: coding test, soft skills, English and a level check
- Free replacements: unlimited on 12+ months, 2 on 6 months, 1 on monthly
- A direct line to our CEO
Terms in plain words
- Monthly, six months or twelve, your choice
- Your rate is locked for the whole contract on 6 and 12+ months
- Monthly ends with 30 days’ notice
- Want to hire the developer full-time? The buyout is set in the contract from day one
Questions tech leads ask us
How senior are your back-end developers?
6+ years of professional back-end work, with recent production experience in the language you hire for. We test the language you name, not a general one.
Can I see the coding test results?
Yes. Every profile card includes the score and the reviewer's notes.
Skip the sales rep. Talk to the CEO.
Tell us what you're building, your stack and when you need people. Three vetted profiles per role within 48 hours of the call, and a straight answer on whether we're the right fit.