Questions engineers ask before applying.

The honest answers. If yours is not here, email [email protected] and we will answer it directly, then probably add it.

The engagement

Is this a job or a contract?

A contract. FDEs are independent contractors engaged per build, not employees. The build engine is deliberately scarce and hand-picked, so there is no constant pipeline and no salary. You keep your independence and invoice in your own name.

How long is a typical engagement?

Usually six to twelve weeks for one production system. The Engagement Lead scopes it and sets a written definition of done before you start, so you are never building into an open-ended brief.

Is it remote or on-site?

Mostly remote, but you build inside the client's environment, which sometimes means on-site time for regulated clients who require it. Banks, hospitals, and governments are the normal case, so expect some engagements to need physical presence or a hardened access path.

What does the Engagement Lead own versus what I own?

The Engagement Lead owns the client relationship, the problem definition, the architecture, and the definition of done. You own shipping the system inside the client's environment and building verification in. You do not sell or scope the deal; that is the Engagement Lead's job, so you can focus on the engineering.

What is the relationship to the bootcamp and the Principal Mentors?

The Principal Mentor runs the transfer half of a build engagement: training the client's operators to own the system after you ship it. You focus on building and verifying; they focus on handover. The bootcamp is the separate training side of Cohorte, and references from build engagements feed it.

Pay and IP

How are engagements paid?

A fixed fee per engagement, or against milestones on a larger build, agreed in writing before you start. The client buys an outcome, not your hours, so shipping efficiently is never punished and there are no timesheets. The fee depends on the engagement: its scope and stakes, your seniority and track record, and the client. We set it at senior market rates for your region and hold to it, with no day-rate haggling once the work is underway.

Who owns the IP I build?

The client. Build-and-transfer means the system and its IP transfer to the client; you and Cohorte retain nothing in their system. This is the opposite of the build-and-leave model where a vendor keeps you dependent. If we offer you an engagement, you sign an FDE agreement that assigns the IP to the client and spells out the transfer.

How does confidentiality and data handling work?

Nothing leaves the client's environment. You build inside their cloud and data boundaries, under NDA, with their compliance constraints as a given rather than an annoyance. The runbook covers the confidentiality and security rules in detail once your access is granted.

The work and fit

What stack do you work in?

Whatever the client's environment requires, plus Cohorte's reference stack for verification and governance (open source at github.com/Cohorte-ai). You are expected to be stack-flexible: the constraint is the client's infrastructure, not our preferences. The runbook documents the reference stack.

Do I need a security clearance or regulated-industry background?

Not formally, but comfort working inside locked-down, audited environments is part of the bar. If you have shipped in finance, health, or the public sector, say so. If you have not, your scenario answer and evidence need to show you can handle the constraints.

How does the review work?

The Engagement Lead reads every application personally. If it moves forward, the next step is a short call about the work and the environments you have shipped into, plus a reference. The roster is small, so the bar is high and the process is fast and direct.