LO
Computer science — where it leads
Several directions, never one. Each says what your training reuses, what graduates typically lack, the real entry conditions, and one thing you can test this term. A degree is not assessed here — the assessment sits on the task, so follow any direction through to its occupation page.
Where it can lead#
Software engineering, entering deliberately
task-level analysis →- What transfers
- All of it — this is the direct path.
- What graduates typically lack
- Not knowledge but evidence of judgement. The traditional first job taught judgement by paying you to write routine code for two years; that arrangement is weakening, so you need to demonstrate review-quality thinking before anyone would normally ask for it.
- Entry reality
- The bottom rung of the ladder is narrower than it was; the top is intact. Read the occupation page — the split between entry-level and senior is sharper here than in any other first-batch occupation.
Take a generated pull request — yours or an open-source one — and write a review that finds a real problem, with the reasoning spelled out. Do it weekly and keep them. That folder is worth more than another finished tutorial project.
Domains where being wrong is expensive
task-level analysis →- What transfers
- Failure reasoning and fundamentals, in the places that keep a human firmly in the loop: payments, security, data integrity, infrastructure.
- What graduates typically lack
- Depth in one specific area, which only time produces. Most graduates have breadth and no depth, which is exactly backwards for this path.
- Entry reality
- Fewer entry-level postings, but the ones that exist are less exposed and better paid. Often reached after a year or two elsewhere rather than directly.
Pick one such area and read a real production system's handling of it end to end — an open-source payment or auth library — until you could explain its failure modes to a classmate.
Between engineering and the problem
- What transfers
- Problem modelling plus the ability to read a system, applied where the value is understanding both the machine and what a person needs from it: solutions engineering, developer experience, technical product.
- What graduates typically lack
- Communication treated as a first-class skill rather than a soft one — writing documentation someone can actually follow, and running a conversation with a person who does not share your vocabulary.
- Entry reality
- Rarely advertised at graduate level, usually entered laterally after some engineering time. Worth knowing it exists early so you build toward it.
Write documentation for something you built, hand it to someone unfamiliar, and watch where they get stuck without helping them. That silence is the lesson.
Engineering thinking in a non-software field
- What transfers
- The whole toolkit, applied where almost nobody can both understand the domain and build. That combination is scarce and does not compete head-on with generation.
- What graduates typically lack
- The domain itself, restarting from near zero — and the patience for a first year that feels like going backwards.
- Entry reality
- No standard path, which cuts both ways: no queue to join, but also nobody recruiting for it. Usually starts from a personal connection to the field.
Find one person in a non-software field with a repetitive problem, and build the smallest thing that actually helps them. One person using it beats a hundred GitHub stars.
Testing and quality engineering
task-level analysis →- What transfers
- Failure reasoning, turned into a job: working out how a system breaks before a user does, and building the harness that keeps proving it.
- What graduates typically lack
- Graduates usually arrive able to write tests for code they wrote themselves, which is the easy case. The job is testing code someone else wrote, under a deadline that belongs to them.
- Entry reality
- One of the more open entry points in software, and often unfairly treated as a lesser one. Read the occupation page before deciding: test generation is one of the tasks with the most verified evidence on this site, and what that evidence changes is which half of the job is left.
Take a classmate's project you did not write, and find three ways to break it that they did not anticipate. Write down which of the three a generated test suite would have caught.
Putting AI into production inside a company
task-level analysis →- What transfers
- Reading a system plus problem modelling, applied to a company that has bought the tools and now needs someone to decide what they may do unattended.
- What graduates typically lack
- Graduates underestimate that most of this is organisational — getting two departments to agree, and standing there when the thing gets something wrong — rather than technical.
- Entry reality
- Rarely a first job and genuinely hard to read from outside: the occupation is young enough that this site marks its confidence low, and most of what is written about it is written by people selling AI implementation services. That is a reason to go and look rather than a reason to avoid it.
Pick a tool a society or lab actually runs on, and write one page on what it currently decides by itself and what should need a person. Show it to whoever owns that tool and see which line they argue with.
The layer people actually touch
task-level analysis →- What transfers
- Problem modelling, in the one place where the undefined cases are visible to a stranger: the states nobody drew — empty, half-loaded, offline, the error that arrives while the user is still typing.
- What graduates typically lack
- Accessibility, which a CS degree almost never teaches and which in many markets is a legal requirement rather than a nicety. Note what that means for this path: the part of the job the degree skipped is the part with a law behind it.
- Entry reality
- The widest entry point in software, and the one where a demo of a generated interface is most frightening to watch. Read the occupation page before drawing a conclusion from that demo: what generates well is the first screen, and the rest of the job is real devices, real networks, and the components everyone else builds on.
Take an interface you built and use it start to finish with the keyboard only, no mouse. Write down the step where you got stuck. Then fix that step — you have just done the part of this job that does not generate.
The pipes, and who answers for what comes out
task-level analysis →- What transfers
- Failure reasoning, aimed at the failure mode this degree teaches you to expect and most people never think about: the one where nothing throws an error and the number is simply wrong.
- What graduates typically lack
- Graduates have written queries; they have not maintained something that breaks at 3am because a system upstream changed a field without telling anyone. Nor has anyone yet asked them to say, in one sentence and on the record, what a number means.
- Entry reality
- A wider door than the machine-learning one and much less crowded, partly because it is less glamorous and partly because the work only becomes visible when it fails. The occupation page is candid that the first task on it — building the pipeline — is the one automating fastest; what is left is the part where someone has to be accountable for the definition.
Build a pipeline that runs by itself every day, then deliberately feed one bad row in at the top and see whether anything tells you. For most people the first time, nothing does — that silence is the whole occupation in one experiment.
Systems whose behaviour is learned
task-level analysis →- What transfers
- Fundamentals and failure reasoning, on systems where no one can explain line by line why they did what they did — so the reasoning has to be statistical instead of mechanical.
- What graduates typically lack
- Experiment design and enough statistics to be suspicious of your own result. And one thing coursework rarely states outright: a model that improves on the offline metric and gets worse for the people it is used on is the normal case, not an accident.
- Entry reality
- Two different doors that get called the same thing. Research-flavoured roles are narrow, heavily postgraduate, and the ones everybody applies to. The wider door is applied work on top of bought models, which is growing and is not advertised under this title. The occupation page splits the job the same way: training a model is the task automating fastest, deciding what counts as good enough is the one that is not.
Train something on a public dataset, then write down where you expect it to be confidently wrong — and go construct those inputs until it is. Deciding what counts as good enough, and proving to yourself it is not, is the half of this job that nobody can hand to a tool.