Company
Careers at DocumentMS
We hire people who are interested in the unglamorous half of software: retention rules, permission models, audit evidence and migrations that cannot lose a file. This page lists current openings, how our interview process runs, and what to expect in the first month.
What we are actually working on
Document management is unglamorous in a way that suits a particular kind of engineer. The interesting problems are retention rules with trigger events set years after a document was created, permission models that have to be finer than read-and-write, audit trails that must remain useful after the document they describe has been destroyed, and migrations that cannot lose a single file because someone will eventually need it in court.
None of that demos well. All of it matters enormously to the people who buy it, and it is the reason the work has a clear right and wrong answer more often than most product work does.
What we look for
- Interest in the boring half of software — correctness, evidence, migrations, edge cases in retention arithmetic
- Willingness to say "we do not do that" to a prospect rather than hedge, and to write it down on a public page
- Comfort with regulated-industry vocabulary, or the appetite to learn it properly rather than approximately
- Care about accessibility and performance as correctness issues rather than as polish
- Scepticism about claims, including our own
Open roles and how we are set up
We do not keep a standing list of open roles on this page, because a stale vacancy is worse than no vacancy. When we are hiring, the role is posted here and on our LinkedIn page at the same time. When we are not, a speculative note is still worth sending — we have hired from them before, and a message that names a specific problem on this site you would want to work on will always get a reply.
The team is distributed, anchored on Nairobi and working across European and East African hours. Roles are remote-first with a deliberate overlap window rather than a required location, and we will say in the posting which hours a role genuinely needs to cover instead of discovering it after you join.
How we interview
Step 1: Conversation
Thirty minutes on what you have worked on and what you want to work on next. No whiteboard.
Step 2: Practical exercise
A realistic problem in the domain, done in your own time with a four-hour limit we actually mean — we read what you did in four hours, not what you could have done in twelve. It is paid at a day rate, because asking for unpaid work is asking candidates with the least spare time to opt out.
Step 3: Technical discussion
A walk through your exercise with two people you would work with, focused on trade-offs rather than on whether you reached our answer.
Step 4: Decision
A decision within 5 working days of the final conversation, with specific feedback either way. If we need longer we will tell you before the five days are up rather than after.
最終レビュー: 2026-09-01