Interview prep guides by topic

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.

The discipline of building the self-service layer other engineers use to ship: developer portals, CI/CD systems, and the guardrails that replace a review step. It succeeds or fails on adoption, not on architecture, which is what makes it a genuinely different job from the infrastructure work it grew out of.

The discipline of finding where a system trusts something it shouldn't and closing that gap before an attacker finds it first - spanning secure code, threat modeling, and the response when prevention fails anyway.

The discipline of delivering an outcome that spans several engineering teams you do not manage. Its content is dependencies, sequencing and risk made visible early enough to act on, and its difficulty is that every commitment you rely on was given voluntarily.

Writing programs that run on a replicated, adversarial, permanently-public machine, and building the ordinary software around them that makes them usable. The engineering is unusually constrained: code is hard to change, every input is hostile, and mistakes are irreversible and public.

The engineering of shared, real-time simulated state across machines that cannot agree on what time it is. Its whole difficulty is that a game must feel instant while the network is not, so every technique in it is a choice about where to put the error.

Software that runs on hardware small enough to have no operating system worth the name, where the requirements come from something physical and the resources are fixed at the moment the board was designed. The skill it rewards is reasoning about worst cases rather than averages.

Designing the logic that becomes a physical circuit, in an ASIC that is manufactured once and fixed forever or an FPGA that can be reprogrammed in seconds. The discipline is defined by two constraints software does not have: everything happens at once, and a mistake in silicon cannot be patched.

The engineering discipline behind automated trading: C++ or similar written against the hardware rather than against a framework, order books held in memory, and a latency budget where the number that matters is the worst case rather than the average. A small field, and an unusually demanding one.

Building the software that runs on a phone the OS can suspend, kill, or starve of memory at any moment - iOS and Android architecture, state that survives what the system does to it, and the discipline of designing for a device you do not control.

Rendering a world that a person wears. The maths of projection, a pipeline that must finish on time every time, and a frame budget that is a comfort requirement rather than a quality setting.

The function that owns a company's relationship with the developers who build on its product: helping them succeed, carrying what they experience back into the product, and making the product known. It has real leverage and almost no formal authority, which is what makes it a distinct discipline rather than a flavour of marketing.

The work of deciding what a product does, in what order a person does it, and how that decision survives being implemented by someone else. Design systems, accessibility and user research are the three parts of it that engineering interviews reliably examine.

Deciding what a reader needs, finding out whether it is true, and putting it where they will reach it in time. The writing is the visible part; the structural judgement and the verification are the parts that are hard to replace.

Coaching above team level is the work of changing how an organisation funds, cuts and coordinates teams. The skills are durable and the dedicated job title is contested: many organisations have cut coaching headcount, and the roles that remain sit inside large multi-team programmes.

The work of making sure a customer gets the result they paid for, after the sale and before the renewal: onboarding an enterprise, growing real adoption, running technical escalations across an integration boundary, and reading an account well enough to know a year early whether it will stay.

Forward deployed engineering is production software work done inside a customer's organisation: their data, their access controls, their competing stakeholders, and a business problem nobody has specified properly. The deliverable is a running system somebody else can own after you leave.

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.

Building product features on top of a model you did not train, where the model is the easy part and evaluation, cost, latency and abuse are the engineering. The hiring bar has moved from knowing the API to proving a change made the feature better.

Most enterprise AI is a retrieval system with a language model at the end of it, and retrieval quality decides the answer far more than model choice does. Permissions, freshness and stage-level evaluation are where these projects actually fail.

The modelling discipline: turning a business decision into a prediction problem, building features that will exist at prediction time, and choosing a metric that corresponds to the decision. Most failures here are framing and leakage failures, not algorithm failures.

The distance between a model that works once and a model a business depends on. Reproducibility, point-in-time correct training data, drift you must detect without labels, GPU economics and model governance are the work, and none of it is modelling.

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.