Work where the software has to keep running.
We build systems we cannot walk away from: a plant that does not stop, a terminal with no maintenance window, a clinical tool a surgeon relies on. That changes what engineering here feels like, and it is not for everybody.
Four things that are different about this job.
None of them is a perk. They are consequences of running what we build, and two of them are demanding rather than pleasant.
You will still be there in year three
We run what we build. That means the decision you make this quarter is one you will live with, which is the fastest way anybody learns to make better ones.
Your name is on the architecture
A named engineer signs the architecture, reads every change before it ships, and approves the release. That is authority as well as accountability, and it is not reserved for a title.
Real constraints, not hypothetical ones
A factory line that cannot stop and a terminal with no maintenance window are not interview questions here. They are the brief.
AI is a tool you are expected to use well
Models write code, tests, documentation and analysis here, and a person reads all of it before any of it ships. Knowing where that line is is part of the job.
What we actually do, most days.
Architecture is written down before the build and signed by a person. Not because a document is valuable in itself, but because a decision nobody wrote down is a decision nobody can be asked about.
Review is a person reading the change, including the parts a model generated. We treat generated code as a draft from a fast contributor with no context, because that is what it is.
The words "it works on my machine" and "we will fix it after launch" both mean the same thing here, and we say so at the time rather than in a retrospective.
Nobody is asked to be heroic about a release. If a release needs heroism, the process is wrong and that is the thing to fix.
How we work
Small teams, owned scope
You own a part of a system rather than a queue of tickets. Ownership is what makes somebody answerable, and being answerable is what makes the work interesting.
Three gates, and people open them
Architecture review, engineering review, production approval. Work moves continuously between them and does not move past one until a named engineer signs.
Written before spoken
Decisions land in a document, not in a meeting somebody has to have attended. That is also what makes distributed work honest.
Dhaka, with clients in five countries
The work is done here. Overlap is arranged around the parts that genuinely need to be synchronous rather than as a blanket promise about hours.
Progression is scope, not title.
Progression here is scope, not title. The step is from owning a component to owning a system to signing an architecture, and each one is a specific, visible thing rather than a review cycle.
The fastest route through it is the unglamorous one: read more code than you write, and take the on-call for something you built.
What you get
Named ownership
Your name on the architecture you signed, and the authority that comes with it.
Real systems, in production
Not a proof of concept. Systems that people depend on, in five countries.
Senior review
Every change you write is read by somebody who will tell you why, which is the only training that compounds.
A stated AI position
You get the tools, and you get a written line around what they are allowed to decide.
That list is short because it is the list of things that are true. We would rather name four than write the fourteen every careers page writes.
Nothing is open right now
We would rather say that than list roles we are not hiring for. We do read unsolicited approaches, and the ones that get a reply are the ones that arrive with something to look at: code, a system you designed, or an account of a decision you would make differently now.
Send it to careers@devtechguru.com with a sentence about what you want to work on.
Four steps, and a decision either way.
No puzzles, no whiteboard algorithms, and no take-home that is really a week of unpaid work.
You send us something real
Code you wrote, a system you designed, or a paragraph about a decision you would make differently now. A CV alone tells us very little.
A conversation with an engineer
Not a screening call. The person you speak to has read what you sent and will disagree with part of it.
A technical session on a real problem
Drawn from work we have actually done. No puzzles, no whiteboard algorithms, no take-home that is really a week of unpaid work.
A decision, with a reason
Yes or no, quickly, and we tell you why either way. Silence after an interview is the rudest thing an employer does routinely.
Not hiring right now does not mean not reading. careers@devtechguru.com, or read what we write about the work first.