Do you need a computer science degree?

There is no licence, no accredited curriculum and no degree requirement for this role. That is not a loophole; it is a consequence of how young the occupation is. Nobody has enough hiring history to say a degree predicts performance here, so screening leans on evidence of having done the work — which a degree may or may not give you.

What actually gets screened

Three things, in this order.

Can you build something that runs for other people? Not a notebook. A deployed service with an error rate, a retry policy and someone besides you who has used it.

Can you talk to a non-engineer about it? The interview version of this is the persuade round described in what an FDE interview tests. The field version is harder: explaining to a plant manager why the model is wrong on Tuesdays without using the word model.

Have you ever been accountable for a number? A latency budget, a conversion rate, a defect count. This is the item that most distinguishes career-changers who succeed from those who stall, and it has nothing to do with a degree.

What a degree does and does not replace

A computer science degree gives three things that matter here, unevenly.

Systems intuition — why a queue backs up, why a timeout cascades, why the database is the bottleneck at 3am. You can learn this without a degree, but you learn it from outages, and outages are expensive for everyone involved. This is the part worth deliberately studying rather than absorbing by accident.

Breadth — networking, storage, concurrency, a bit of distributed systems. An FDE meets all of these in customer environments, often on the customer's terms rather than a cloud provider's defaults.

Credential value — low and falling for this role specifically. It matters more when the customer is a bank or a state-owned enterprise and the vendor is selling a team, not a person.

What a degree does not give you is the thing the job is made of: judgement about which problem to solve, and the temperament to sit in a room where you are the only person who understands the system and the least senior person present.

The paths that are harder without one

Being honest about this is more useful than the general encouragement. Two paths are measurably harder without formal CS training.

Infrastructure-heavy deployment — on-premise installations, air-gapped environments, Kubernetes inside a customer's data centre. These reward the systems intuition above and punish improvisation, because a mistake takes down something you cannot see.

Model-adjacent work — evaluation design, fine-tuning, inference optimisation. Not because the maths is inaccessible, but because the hiring bar for these roles is set by people who have it, and they screen on it.

The paths that are easier without one are equally real: vertical deployments where the domain matters more than the stack, product-facing AI work, and deployment roles at companies that hire for delivery rather than for research.

What to build instead of enrolling

If you are deciding, the cheapest experiment is a two-week build with a real user. Pick a workflow in a domain you already know, build the narrow version, and get one person who is not you to use it daily for two weeks. Then write the four-paragraph readout: what it was supposed to do, what it did, what broke, and what you would do differently.

That artefact answers more of the screening questions than a transcript does, and it is the same shape as the portfolio evidence described in how people become FDEs. A course can substitute for the structure of a curriculum; nothing substitutes for the two weeks.

The honest summary

No degree is required. The fundamentals are not optional. If you have neither the degree nor the fundamentals, the gap is real and it is closable — but it closes through systems you operate, not through certificates you collect.