Careers
We hire engineers who are willing to be responsible for the outcome.
Two roles, both senior, both hands on keyboard. There is no bench, no pyramid and no path here that leads away from code. If you want to stop writing software in three years, this is the wrong firm.
The job
You sit in someone else's team, you write code, and their outcome is your score.
Forward Deployed Engineer is a title that has been used loosely, so here is the version we mean, with nothing softened.
You are embedded
You join a client standup, a client repository, a client Slack and, on most engagements, a client incident rotation. You are introduced by name, you stay for the engagement, and the client can ask for a different engineer on two weeks notice — which is a real accountability, not a formality.
You write the code
A merged pull request in the first two days is the bar, even if it is a typo fix, because it proves the path from laptop to production works. There is no analyst upstream of you writing requirements and no offshore team downstream implementing them. You are the engineer.
You are measured on their outcome
Not utilisation. Not hours booked. Whether the system replaced the thing it was meant to replace, on the date, with the data reconciled and a team who can run it. That is a harder measure than a timesheet, and it is the reason the job pays what it pays.
Fit
Who this suits, and who it does not.
The second list is longer on purpose. Most of the people who leave this kind of role leave because of something on it, and we would rather that came up in the intro call.
Suits you if
- You have been the person who owned a system in production and were called when it broke.
- You enjoy landing in an unfamiliar codebase and being useful inside a week.
- You can say no to a stakeholder, in a meeting, with a reason, without it becoming a conflict.
- You would rather ship a narrow thing that works than a broad thing that demos.
- You are comfortable that the parity table has rows where the answer is no, and that saying so is part of the job.
- You want to work with AI tooling seriously and are equally interested in where it is wrong.
Does not suit you if
- You want one codebase, one team and one set of conventions for the next four years. This job changes context every few months.
- You want a management track. There is very little management here and none of it comes with leaving code behind.
- You dislike being observed. Working inside a client team means your commits, your estimates and your mistakes are visible to people who are paying for them.
- You need requirements handed to you. Most of week one is deciding what the requirements are.
- You cannot travel at all. Some engagements need you on site, and that is described honestly below rather than discovered later.
- You would find it uncomfortable to tell a client, in writing, that they should keep paying their existing vendor.
Open roles
Two roles. Both senior, both writing code.
Two open positions, one remote in Canada and one remote in the United States. Both are senior, both are hands on keyboard, and both need six or more years of production full-stack engineering.
Sr. Forward Deployed Engineer — AI and Automation
OpenYou sit inside a client team and ship in their repository.
The core role. You are the named engineer on an engagement from the first access request to the handover, and you are measured on whether the client system works — not on hours booked, not on documents produced.
What you do
- Write production code in the client codebase, from week one
- Run the usage audit: audit logs, invoices, and interviews with the people who use the incumbent
- Own the parity matrix, including the rows where the answer is no
- Design and cost the AWS or Azure architecture, and write the ADRs
- Migrate the data, run in parallel, rehearse the cutover, hold hypercare
- Leave documentation and a trained team behind you
What we look for
- Six or more years writing production full-stack software, and recent commits to prove it
- Depth in TypeScript or Go or Python, and fluency in Postgres and SQL that is not ORM-shaped
- Real AWS or Azure, with infrastructure as code — Terraform, CDK or Bicep
- You have migrated data between two live systems and reconciled it afterwards
- You can hold a room with a sceptical head of engineering and a nervous CFO in it
- You work with AI tooling daily and have an informed view of where it is unreliable
Sr. Forward Deployed Engineer — SaaS and Cloud Platform
OpenYou make the ground the applications land on, twice.
Every application in Techtons ships with a production architecture for both clouds, on a landing zone that passes an audit. You build and maintain that baseline, and you are the person on an engagement who owns the cloud account boundary, the pipeline and the cost model.
What you do
- Multi-account and multi-subscription landing zones: network, identity, logging, guardrails
- Terraform for AWS and Bicep for Azure, on the same architecture, kept genuinely in step
- CI/CD, secrets, observability baselines and the deployment path from laptop to production
- Cost engineering: right-sizing, savings plans and reservations, and the estimates published on this site
- Production readiness reviews and the on-call runbooks that follow them
- Client cloud accounts, which means their compliance boundary is your problem
What we look for
- Six or more years writing production full-stack software, including platform and infrastructure work, in production and on call
- Deep in at least one of AWS or Azure and genuinely working in the other
- Terraform to a high standard: modules, state strategy, drift, and a plan you can read
- Kubernetes or serverless container platforms, and an opinion about when not to use them
- You have been the person who explained a cloud bill to a finance director
- Security as a default, not a review gate
Travel and client sites
The honest paragraph about travel.
This is a forward deployed role, and forward deployed means what it says. Most of the work is remote, in the client repository and the client Slack, and most weeks you will not go anywhere. But the first week of an engagement is almost always on site, because being in the room when you are asking for access, watching someone use the incumbent and meeting the sceptics is worth more than four weeks of video calls. Cutover weeks are usually on site as well, for the same reason: when the migration is running, you want to be where the people are.
In practice that has meant a few days on a client site at the start of an engagement, occasional days for workshops or steering reviews, and a concentrated period around go-live. Some clients require on-site presence more often than that, for security or cultural reasons, and when they do we say so in the interview rather than after you have signed. Travel and accommodation are paid by us, booked to a sensible standard, and never a taxable perk dressed up as a benefit.
If you cannot travel at all, say so in the intro call. It does not automatically rule you out — some engagements genuinely never need it — but it will limit which projects you can take, and it is better to know that on both sides at the start.
Interview process
Four stages. About four hours of your time, plus the exercise.
We aim to get from first call to decision in under three weeks, and we will tell you where you stand after every stage, including when the answer is no.
Intro call
30 minutes, with an engineer
Not a screen with a recruiter reading a checklist. An engineer talks to you about what you have built, what you are looking for, and what this job actually involves — including the travel. You should leave able to decide whether you want the next stage.
Technical conversation
90 minutes, two engineers
We read code together. Bring something you have written and can talk about, or use ours from Techtons. We will ask why, and we will disagree with you in places to see how that goes. No algorithm puzzles, no whiteboard, no questions about linked lists.
A practical exercise
Four hours maximum, at a time you choose
A small, realistic problem — read an unfamiliar schema, migrate some data, and be honest about what you did not finish. We cap it at four hours and we mean the cap: if a candidate tells us it took longer, we shorten the exercise for the next person. Anything we ask for beyond four hours is paid at a day rate agreed before you start.
The client conversation
60 minutes, with a founder and a senior engineer
The part of the job that is not code. You will be given a real situation — a contract, a usage picture, a sceptical stakeholder — and asked what you would say. We are looking for someone who can say no clearly and explain why. Then references, an offer with the band we advertised, and a start date.
Two promises about the exercise
No take-home we set will be longer than four hours, and we will not pretend a twelve-hour task is a four-hour one. If we ask you for anything beyond that — a longer piece of work, a paid trial day, a session with a real client problem — it is paid at a day rate agreed in writing before you start it, whether or not you get the job. Unpaid work for a company you do not work for is not an interview, it is a favour.
Pay
We discuss it with you directly.
No figures are published on this page. Compensation is set by level and by location, and we will give you the number in the intro call if you ask — a number, not a range with no top. We do not ask for your current salary and we do not ask for your expectations as a screening question.
There is no commission, no utilisation bonus and no incentive tied to hours billed, because either of those would change the advice our engineers give. If your work makes an engagement finish early, that is the outcome the whole firm is arranged around.
How to apply
Email support@conseiltek.com with the role and the country in the subject line. Send two things:
- 01
Your CV
However you keep it. A GitHub profile or a repository you are proud of is welcome alongside it, and is often more use to us than the CV.
- 02
One slide deck about your work
A single PowerPoint covering the projects you have worked on and, specifically, what your role was in your current position — what you built, what you decided, and what you would do differently. We read it before the intro call, and it is what the technical conversation starts from.
Do not send anything covered by an NDA. Describe the shape of the problem and your part in it; we would rather read that than see a diagram you should not be sharing.
If you want to know what the work looks like before you apply, read a repository in Techtons — the parity matrices and cost models are written by the same engineers who would interview you — or read what a Forward Deployed Engineer does in week one.