Learn the areas

DSA is the study of how to organise data and traverse it efficiently, and the vocabulary of patterns that lets you recognise which technique a new problem wants. Its demand is driven mostly by hiring filters rather than daily work, but the pattern recognition genuinely transfers.

System design is deciding how services, stores, caches and queues fit together to meet stated requirements, and defending why you gave up one property to get another. The round tests structured thinking under ambiguity, not recall of a reference architecture.

Low-level design is the round where you produce classes, interfaces and interactions inside one service rather than infrastructure boxes. It scores where you put boundaries, what you name things, how the design absorbs the next requirement, and whether the code runs before the timer stops.

Nobody implements a B-tree at work, yet the core subjects keep being asked, because how someone explains paging or an index is the cheapest available predictor of how they will reason about an unfamiliar system under pressure.

The server-side work of exposing behaviour over a network, protecting it, and keeping it correct when the things it depends on fail. It is the space between a coding round and a system design round, and the skill it rewards is designing for partial failure.

Building the part of a system a person operates directly: the browser as a runtime with its own scheduling and rendering rules, state and component architecture at the point where senior work actually lives, performance measured against real devices, and accessibility as both a craft and a legal obligation.

The layer where almost every serious performance problem eventually turns up: how data is modelled, how indexes and query plans decide whether a query takes a millisecond or a minute, what a transaction really promises under concurrency, and where a non-relational store genuinely fits.

The discipline of running software in production: Linux and networking underneath, containers and Kubernetes in the middle, infrastructure as code and pipelines around it, and reliability treated as a budget you spend rather than a target you hit.

The discipline of finding out whether software works before customers do, and of saying how much confidence you have and why. It spans exploratory craft, automation engineering, API and performance testing, and the judgement to articulate release risk.

The work of moving data reliably, modelling it so people can trust an answer, and putting statistical or language models into production. Five different jobs hide under one label, and confusing them is the most common reason a career move here goes sideways.

Java is the default language of large enterprise back ends, and most Java jobs are really Spring jobs sitting on a JVM you are expected to understand. Demand is enormous, and much of the work is modernising estates that already exist.

Python is three fairly separate job markets — backend web, data and machine learning, and automation — that share a syntax and almost nothing else. Interviews differ sharply between them, so saying you know Python conveys much less than it sounds like.

Node.js runs JavaScript on the server on a single-threaded event loop, and TypeScript is now how almost everyone writes it. The draw is one language across the whole stack; the price is that CPU-bound work has to be deliberately pushed somewhere else.

One language, two job markets — modern cross-platform .NET running on Linux and in containers, and .NET Framework keeping Windows-only systems alive that still fund a great deal of the work. Find out which one a role means before you prepare for it.

Go is deliberately small — one obvious way to do most things, a compiler that finishes in seconds, and a single static binary at the end. That smallness is the actual value proposition, and it shapes the interview, because there is no framework knowledge to hide behind.

Architecture is the set of decisions that are expensive to reverse - boundaries, data ownership, integration style - chosen against conflicting quality attributes. The title means wildly different things across companies, so establishing which job is being hired is the candidate's first task.

Engineering management is accountability for a team's output, health and careers rather than for code. It is a change of profession, not a promotion: the skills barely overlap with senior engineering, and the interview tests judgement under ambiguity rather than knowledge.

Scrum is a small framework that most organisations adopt partially and then blame. The facilitation and flow skills remain genuinely valuable; the dedicated Scrum Master job is a much narrower market than the certification industry implies, and is increasingly absorbed by EMs and tech leads.

Business analysis is finding out what an organisation genuinely needs and writing it down precisely enough to build and to test. The artefacts change every few years; elicitation and precision do not. Demand is steady in regulated enterprises and thin in product startups.

Product management is deciding what a team builds and why, and being accountable for the outcome without owning the people who build it. The job splits three ways — discovery, prioritisation, execution — and most of it is writing and persuasion.

Presales solution engineering is the technical half of a sale: designing, demonstrating and pricing an answer to a customer's business problem before anyone has bought anything. It is engineering under commercial constraint, and the deliverable is being believed by the buyer and by your own delivery team.

The behavioural round is a structured assessment of how you have worked with other people, scored against a written competency rubric rather than on how likeable you seemed. It is where senior candidates are rejected most often, and it rewards a small bank of real stories over memorised answers.

The recruiter screen and the offer conversation are the two points in a hiring process where an unprepared candidate loses something irrecoverable: the loop they never got, or the money they never asked for. Almost nobody prepares for either, which is what makes an hour of thought disproportionately valuable.

Domain knowledge is understanding what a system's transactions mean to the business that runs it — settlement, claims, prior authorisation, inventory — and it is the thing that most often decides between two technically equal candidates.

How money is recorded and moved: the double-entry ledger that makes a balance derivable rather than stored, the split between authorisation, clearing and settlement, the card and real-time rails that carry value, and the reconciliation and compliance work around both.

Capital markets engineering is the software behind buying and selling securities: order routing and matching, market data feeds, and the clearing and settlement plumbing that turns a fill into ownership. It is a narrow field that pays for depth.

Insurance software is dominated by two forces: products that must be configurable per state, per year and per channel, and data that must stay correct as of any date in the past.

Healthcare software is built around a patient record nobody owns end to end, two interoperability standards that both refuse to die, a billing layer that pays for everything, and users who cannot be interrupted.

Retail commerce as an engineering domain: the path from browsing a catalogue to a delivered parcel, and the places it gets genuinely hard, which are product data, search relevance, inventory consistency and the promotions engine.

The systems that plan, move and account for physical goods from order to doorstep. Every hard problem here comes from the same place: the goods are real, they do not roll back, and what the software believes is only ever an approximation of where they are.

Telecom software divides into OSS, which runs the network, and BSS, which runs the commercial relationship with the subscriber. Most engineering work is integrating and modernising that estate rather than building it new.

Manufacturing software is defined by the boundary between OT, the control systems that move machinery, and IT, where your code usually lives. Crossing that boundary safely is most of the job.

Regulation is a design input, not paperwork bolted on at the end. This is how privacy, residency, auditability and access rules reach into a system, and how a control is evidenced rather than asserted.