Software engineering decoded

Software engineers write precise instructions that tell computers what to do, then keep those instructions working as the product, its users and its business grow. Writing new code is only part of the job: much of an engineer's week goes on reading other people's code, fixing problems, reviewing work, testing, and deciding how things should be built.

This is the longest module in the course because engineering is where recruiters get most confused. Take it in parts. Every term is explained the first time it appears, and each part ends with what it means for you as a recruiter.

2.1 What is code, really?

Code is a recipe for a computer. A recipe says: take 200g of flour, add two eggs, mix for three minutes, bake at 180°C. A computer is like a very fast cook who follows instructions perfectly but has zero common sense. If the recipe says "add eggs" without saying how many, it gets stuck. If the recipe has a mistake, the computer follows the mistake perfectly. That's a bug.

So an engineer's real skill isn't typing. It's breaking a messy real-world problem into small, precise, unambiguous steps, and thinking ahead about everything that could go wrong. For example: what if the user types their email wrong? What if 10,000 people press "Buy" at the same second? What if the payment provider is down?

Programming languages are like human languages. English, French and Spanish can all express the same ideas, with different grammar and different strengths. In the same way, Java, Python and JavaScript can all build software, but each suits some jobs better than others. And just as someone fluent in Spanish picks up Italian quickly, an engineer fluent in Java picks up C# quickly. This is the single most useful idea for widening your talent pool.

A few more basics:

• Program / application / app: a finished set of instructions that does something useful (Spotify, a banking app).
• Codebase: all the code for one product. Large products have millions of lines, written by hundreds of people over many years. Imagine an enormous shared cookbook that many chefs keep editing at once.
• Framework: a ready-made kit that handles common jobs so engineers don't start from scratch. Think of a flat-pack kitchen: you still assemble and customise it, but you don't cut the wood yourself. React, Django and Spring Boot are frameworks.
• Library / package: a smaller ready-made tool for one specific job, like buying a ready-made sauce instead of making it.
• Open source: code that anyone can see, use and improve for free. Much of the internet runs on it.

2.2 What engineers actually do all week

A typical week for a mid-level engineer looks roughly like this (it varies a lot by company and level):

Senior engineers spend less time writing code and more time designing systems, reviewing others' work, mentoring and making decisions. That's why "years of coding" is a poor measure of seniority.

Engineers increasingly use AI coding assistants (tools such as GitHub Copilot, Cursor or Claude Code) that suggest or write code for them. This doesn't remove the need for engineers. It shifts the job further towards judgement: deciding what to build, checking the AI's work and designing systems well. It's a good topic to ask candidates about.

2.3 How an app works: the restaurant

Almost every product has the same basic parts. A restaurant is the easiest way to picture them.

Two more words you'll hear constantly:

• Client: the device and app in the user's hand: the app on their phone, or the web browser (Chrome, Safari) on their laptop. It's the customer at the table. It shows the menu and takes the order, but it doesn't cook anything.
• Server: a powerful computer the company runs (usually rented in the cloud) that does the real work and sends the answers back. It's the kitchen.
• Example: when you open Instagram, your phone (the client) asks Instagram's computers (the servers) "what's new for me?". The servers find the latest photos and send them back, and your phone displays them.
• So client-side means the frontend (what happens on the user's device), and server-side means the backend (what happens on the company's computers).

2.4 One tap, step by step

Here's what happens in about one second when you tap "Order" on a food delivery app. Every step is a different engineering specialism.

1. You tap the button on the screen. The button, its colour and the screen around it were built by a mobile engineer (or frontend engineer on the website).
2. The app sends a request across the internet to the company's servers, using an API. It's like the waiter carrying your order slip to the kitchen.
3. The backend checks you are who you say you are (authentication), then runs the business rules: is the restaurant open? Is the address in range? What's the total with delivery fee? This is the backend engineer's work.
4. The backend asks the payment provider (such as Stripe) to charge your card. Connecting to outside services like this is called an integration.
5. Your order is saved to the database, so it isn't lost if anything crashes.
6. A message is sent to the restaurant's tablet and a courier is found. Big systems pass these jobs between separate services using queues, like order tickets on the rail in a kitchen.
7. The backend sends a response back to your phone: "Order confirmed". The app shows a confirmation screen.
8. All of this ran on rented computers in a data centre (the cloud), kept running, monitored and scaled up at dinner time by DevOps / SRE engineers.
9. Your order is recorded for analysis, so data engineers and analysts can later answer questions such as "which restaurants sell most on Fridays?"
10. A machine-learning model may have recommended that restaurant to you and estimated the delivery time. That's built by ML engineers.

If you can retell this story, you understand how the main engineering roles fit together.

Recruiter takeaway for 2.1–2.4: when a hiring manager describes a role, place it in the restaurant. "Building our checkout screens" is the dining room (frontend). "Our payments API" is the kitchen and menu (backend). "Moving us to Kubernetes" is the building (DevOps / platform).

2.5 Frontend engineering in depth

In one line: frontend engineers build the part of a website or web app that people see and interact with, turning a designer's pictures into something that actually works in a browser.

The three building blocks: a house

Every web page is made from three languages working together. Picture a house:

TypeScript is JavaScript with built-in spell-checking. Engineers label what kind of information everything holds (a number, a name, a date), and TypeScript warns them before mistakes reach users. Most modern companies now ask for TypeScript. If someone knows JavaScript well, they can learn TypeScript in a few weeks.

Frameworks: flat-pack kits

Building a big web app with only HTML, CSS and JavaScript would be like building a kitchen by cutting every board yourself. Frameworks are ready-made kits:

• React (made by Meta) is by far the most common. It works like LEGO: engineers build small reusable pieces called components (a button, a search bar, a product card) and snap them together into pages. Fix the button once, and it's fixed everywhere.
• Next.js is built on top of React and adds extras such as faster page loading and better visibility on Google.
• Vue and Svelte are popular alternatives, a bit simpler to learn.
• Angular (made by Google) is a bigger, more structured framework. It's common in banks, large corporates and older enterprise systems.

All of these do the same core job. A strong React engineer can learn Vue in weeks. Angular is a bigger jump but still very learnable.

Other frontend words you'll see on CVs

• Responsive design: the page rearranges itself to fit a phone, tablet or big monitor, like water taking the shape of its glass.
• Accessibility (a11y): making the site usable by people with disabilities, for example people using screen readers (software that reads the page aloud) or only a keyboard. The standard is called WCAG.
• Performance / web vitals: how fast the page loads and responds. Every extra second of loading time loses customers.
• State management (Redux, Zustand, React Query): keeping track of what's happening on screen, such as what's in your basket, whether you're logged in, or which tab is open. Think of it as the app's short-term memory.
• Design system / component library: a shared set of ready-built components that match the designers' design system (see Module 3).
• Cross-browser testing: checking the site works in Chrome, Safari, Firefox and Edge.
• SEO (search engine optimisation): helping Google find and rank the pages.
• Micro-frontends: splitting a huge website into separately built sections owned by different teams.
• Build tools (Webpack, Vite): the machinery that packages code so browsers can load it quickly.
• Testing tools (Jest, Vitest, Cypress, Playwright, React Testing Library): automated checks that the screens work.

What good looks like

A strong frontend engineer builds screens that look exactly like the design, load fast, work on every device and for every user, and hold up as the product grows. They work closely with designers and often push back usefully ("this animation will slow the page down; here's an alternative").

Decoding a frontend CV line:

"Led migration of legacy AngularJS app to React/TypeScript, building a shared component library and improving Largest Contentful Paint by 45%."

In plain English: they moved an old website onto modern technology, built reusable LEGO pieces other teams could use, and made the main content of the page load nearly twice as fast. That's a strong, senior-sounding line: ownership, modernisation, reuse and a measurable result.

2.6 Backend engineering in depth

In one line: backend engineers build the hidden machinery behind a product (the rules, the data and the connections to other systems) so that every tap on the frontend gets the right answer, quickly and securely.

The kitchen

If the frontend is the dining room, the backend is the kitchen. Customers never see it, but it decides whether the food arrives, whether it's right, and whether the restaurant survives the Friday rush. Backend work includes:

• Business logic: the rules of the business written as code. "Free delivery over £25." "Users under 18 can't open this account." "Refunds are allowed within 30 days."
• APIs: the menu other software orders from (more below).
• Databases: storing and retrieving information safely.
• Integrations: connecting to outside services such as payments (Stripe), email (SendGrid), maps (Google Maps) or a bank's systems.
• Authentication and authorisation: checking who you are and what you're allowed to do.
• Performance and scale: keeping everything fast when traffic jumps from 1,000 to 1 million users.

APIs: the menu and the waiter

An API is a menu that one piece of software offers to another. The menu lists what you can order ("get my order history", "create a payment") and exactly how to ask. You don't need to know how the kitchen cooks it.

• REST is the most common style of API. It's like ordering from a fixed menu: each dish has its own line.
• GraphQL is like a build-your-own menu: you list exactly what you want on one ticket and get just that back.
• gRPC is a very fast style used mostly for systems talking to each other internally.
• Third-party / public API: a menu a company offers to outsiders. Stripe's entire business is selling access to its payments API.

Databases: where the information lives

SQL (often said "sequel") is also the name of the language used to ask relational databases questions, such as "show me all orders over £100 from last week". Backend engineers, data engineers and data analysts all use it.

Caching means keeping popular things close at hand. A coffee shop doesn't grind fresh beans for every flat white at rush hour; it keeps some ready. A cache keeps popular answers ready so the database doesn't get asked the same question a million times.

Security basics every backend engineer handles

• Authentication = who are you? Like showing ID at the door. (Logins, passwords, "Sign in with Google", OAuth.)
• Authorisation = what are you allowed to do? Like the wristband that says whether you can enter the VIP area. (Admin vs normal user.)
• Encryption = scrambling data so only the right people can read it, like a letter written in code.

Scaling: surviving the Friday rush

• Scalability: the ability to serve many more users without slowing down or breaking.
• Vertical scaling: buying a bigger kitchen (one more powerful computer). Simple, but there's a limit.
• Horizontal scaling: opening more kitchens that share the work (many computers). Harder, but almost unlimited.
• Load balancer: the host at the door sending each customer to whichever kitchen is least busy.
• Queue / message broker (Kafka, RabbitMQ, SQS): the ticket rail in a kitchen. Orders wait their turn instead of overwhelming the chefs.
• Latency: delay. How long it takes to get an answer back. Low latency means fast.

Monolith vs microservices: one big shop or a shopping centre

• A monolith is one big department store: everything in one building, under one roof. Simple to start, but as it grows, changing one department risks disrupting the whole store.
• Microservices are a shopping centre of small independent shops (payments, search, notifications), each run by its own team. Teams can change their shop without closing the centre, but you now need corridors, signage and security between shops. That's extra complexity.

Many startups begin with a monolith and break it into microservices as they grow. "Migrating from a monolith to microservices" is a very common line on senior CVs.

Common backend languages and frameworks

Decoding a backend CV line:

"Designed event-driven microservices in Go on Kafka, reducing p99 latency from 800ms to 120ms and supporting 5x growth in transaction volume."

In plain English: they designed a set of small independent services that pass messages along a ticket rail. They made the slowest 1% of responses about six times faster (from under a second to a tenth of a second) and the system can now handle five times as many payments. "p99" means the slowest 1% of requests: a sign the candidate measures performance properly.

2.7 Full-stack engineering

In one line: full-stack engineers work on both the frontend and the backend, so they can build a feature from the screen all the way to the database.

Think of a chef who can also run front of house. Very useful in a small restaurant; in a big one, you usually want specialists.

• Common in startups and small teams, where people need to wear many hats.
• A popular stack: React + Node.js (both JavaScript/TypeScript) + PostgreSQL. Others: React + Python (Django), Vue + PHP (Laravel), React + Ruby on Rails.
• The reality check: most full-stack engineers lean one way. Always ask: "Roughly what share of your time is frontend versus backend?" A "full-stack" engineer who has spent 90% of their time on React is really a frontend engineer, and that matters if the role is backend-heavy.
• Watch for "T-shaped": deep in one area, comfortable in the other. That's what most hiring managers really want.

Recruiter takeaway for 2.5–2.7: in the intake, ask the hiring manager to split the role by percentage: frontend, backend, infrastructure. Then ask candidates the same question. Matching those two splits will save more mis-hires than matching keyword lists.

2.8 Mobile engineering in depth

In one line: mobile engineers build the apps you download onto your phone from the Apple App Store or Google Play.

Phones have two main operating systems (the phone's underlying software), and they're built very differently:

Native vs cross-platform: tailored suit vs off-the-rack

• Native means building two separate apps, one in Swift for iPhone and one in Kotlin for Android. It's like a tailored suit for each customer: the best fit, the smoothest feel, full access to the phone's camera, sensors and latest features, but you pay twice.
• Cross-platform means one codebase that runs on both phones. It's like a good off-the-rack suit: cheaper and faster, fits most people well, occasionally needs alterations. The two big options are React Native (uses JavaScript/TypeScript and React, so web engineers can move into it) and Flutter (uses a language called Dart, made by Google).

What makes mobile different from web

• App store releases: a website can be updated instantly. A phone app must go through Apple's and Google's review before users can download the new version, so mistakes are harder to undo.
• Offline and battery: apps must cope with weak signal and shouldn't drain the battery.
• Device variety: Android runs on thousands of different phone models and screen sizes.
• Push notifications, in-app purchases, deep links (links that open a specific screen inside an app): all mobile-specific skills.

Recruiter traps:

• An iOS engineer is not automatically an Android engineer, and vice versa. Treat them as separate skill sets unless the CV shows both.
• A React Native engineer may come from web (React) and be weaker on native phone features. Ask whether they've written any Swift or Kotlin.
• A "mobile developer" on a CV could mean any of the above. Always ask which platform and which language.

Decoding a mobile CV line:

"Rebuilt onboarding in SwiftUI with modular architecture; crash-free sessions up from 97.1% to 99.6%; app rating 3.8 → 4.6."

In plain English: they rebuilt the sign-up screens on iPhone with modern Apple technology, organised the code so it's easier to change, and made the app crash far less, which pushed the App Store rating up significantly.

2.9 Cloud, DevOps, Platform and SRE in depth

In one line: these engineers build and run the foundations every other engineer relies on: the computers, the automated release process, and the alarms that go off when something breaks.

The cloud: renting instead of owning

Twenty years ago, companies bought their own computers (servers) and kept them in a cupboard or a rented room. Now most rent computing power from a cloud provider, the way you get electricity from the grid instead of running your own generator. You pay for what you use, and can use more at peak times.

The concepts are the same across all three, so an AWS engineer can learn Azure. Certifications such as AWS Solutions Architect or Azure Administrator show knowledge, but hands-on experience matters more.

On-premise (on-prem) means a company still runs its own servers. Hybrid means some of both. Cloud migration means moving from owning to renting.

Containers and Kubernetes: shipping containers and the port

• Before shipping containers, every cargo ship was loaded by hand with sacks, barrels and crates of every size. Containers standardised everything: any crane, ship or lorry can carry any container.
• Docker does the same for software. It packs an application and everything it needs into a standard container that runs the same on a laptop, a test machine or the cloud. No more "but it worked on my computer".
• Kubernetes (often written K8s, said "kates") is the port authority. It decides which containers run on which computers, restarts any that crash, and adds more when demand rises. Running Kubernetes well is a specialist skill and a common requirement for senior DevOps roles.

CI/CD: the factory assembly line

CI/CD stands for Continuous Integration / Continuous Delivery (or Deployment). Picture a car factory line with quality checks at every station:

1. An engineer finishes a change and submits it.
2. The line automatically builds it (assembles the parts).
3. It runs thousands of automated tests (quality checks).
4. If everything passes, it's released to a test environment, then to real users. If anything fails, the line stops and the engineer is told.

The tools are GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps. Strong teams release many times a day; weaker ones once a month with a lot of manual effort and fear. Asking a candidate "how often does your team release, and how?" tells you a lot about how modern the company is.

Infrastructure as Code: the building's blueprint

Instead of clicking around a website to set up servers by hand, engineers write the whole setup as a file, like an architect's blueprint. If the building burns down, you can rebuild an identical one from the blueprint in minutes. Tools: Terraform (the most common), Pulumi, CloudFormation (AWS), Bicep (Azure). Ansible and Chef handle setting up the inside of each machine.

Monitoring and on-call: smoke alarms and the emergency plumber

• Monitoring / observability: dashboards and alarms that show whether everything is healthy, like smoke alarms and CCTV for the system. Tools: Datadog, Grafana, Prometheus, New Relic, Splunk, PagerDuty.
• Logs: a detailed diary every system keeps of what it did, used to investigate problems.
• Incident: something is broken for users, such as checkout failing. Teams follow an incident process and afterwards write a post-mortem: what happened, why, and how to stop it happening again (without blaming individuals).
• On-call: taking turns to be the emergency plumber, reachable out of hours to fix outages. It usually comes with extra pay. Always ask about on-call in the intake and tell candidates upfront; it's a lifestyle factor.
• Uptime / availability: the share of time a system works. "Three nines" (99.9%) allows about 8.8 hours of downtime a year; "four nines" (99.99%) about 53 minutes. Each extra nine is much harder and more expensive.
• SLA / SLO: the promised level of reliability (an SLA is a contract with customers; an SLO is an internal target).

The job titles (they overlap a lot)

Decoding a DevOps CV line:

"Migrated 40 services from EC2 to EKS using Terraform and ArgoCD; cut deploy time from 45 minutes to 6 and reduced AWS spend 30%."

In plain English: they moved 40 parts of the product from plain rented servers on Amazon to Amazon's managed Kubernetes (the port authority), wrote the whole setup as blueprints, automated releases, made releasing seven times faster and cut the cloud bill by almost a third. (EC2 = Amazon's basic rented servers; EKS = Amazon's Kubernetes service; ArgoCD = a tool that releases to Kubernetes automatically.)

Recruiter takeaway for 2.8–2.9: for mobile, always pin down the platform (iOS, Android, cross-platform) and the language. For DevOps-type roles, pin down which cloud, whether Kubernetes is essential, and what on-call looks like. Titles in this area overlap so much that the hiring manager's description of the day-to-day matters more than the title.

2.10 Data roles in depth

In one line: data roles collect, organise and make sense of the information a business produces, so people can make better decisions and products can get smarter.

The water analogy

Think of a city's water supply:

• The Data Engineer builds the reservoirs, pipes and treatment works: getting raw data from everywhere (the app, the payment system, marketing tools), cleaning it and delivering it to one place.
• The Analytics Engineer sets up the taps and meters in each building: shaping clean data into tidy, trusted tables people can use.
• The Data Analyst reads the meters and reports: "water use rose 12% in June, mostly in the north". They answer business questions with dashboards and reports.
• The Data Scientist predicts the next drought: using statistics and models to forecast, explain and run experiments.
• The ML Engineer builds the automatic valve that adjusts the flow by itself in real time, putting predictive models into the live product.

Key data terms

• Data warehouse: one big, organised library where all the company's cleaned data lives for analysis. Examples: Snowflake, BigQuery, Redshift, Databricks.
• Data lake: a giant storage room where raw data is dumped before it's organised. A lakehouse combines both.
• ETL / ELT: Extract, Transform, Load. Collect data from sources, clean it, and store it. The core of data engineering.
• Pipeline: an automated route data travels along, often scheduled every hour or night. Tools: Airflow, dbt, Fivetran, Spark (for very large data), Kafka (for real-time streams).
• Batch vs streaming: batch = processing data in chunks (overnight); streaming = processing it the moment it arrives (fraud checks on a card payment).
• BI (business intelligence) tools: dashboard software. Tableau, Power BI, Looker, Metabase.
• A/B test: an experiment comparing two versions with real users to see which works better (see Module 4).
• Statistical significance: confidence that a result isn't just luck.

Recruiter trap: "Data Scientist" means very different things at different companies. At some it's a senior analyst; at others it's a PhD-level modeller. Ask the hiring manager for examples of last quarter's work.

2.11 Machine learning and AI engineering in depth

In one line: ML and AI engineers build products that learn from examples, rather than following rules a person wrote by hand.

How machine learning works, simply

Teaching a toddler what a cat is, you don't write rules ("four legs, whiskers, pointy ears"). You point at lots of cats and dogs until they get it. Machine learning works the same way: show a computer thousands of examples (emails marked spam or not spam) and it learns the pattern itself.

• Model: the "brain" that results from that learning. It takes something in (an email) and gives an answer out (spam: 97% likely).
• Training: the learning stage, showing the model examples. Expensive and slow.
• Inference: using the trained model to answer new questions. This is what happens every time you use it.
• Training data: the examples. Poor examples make a poor model ("rubbish in, rubbish out").
• Deep learning / neural networks: a powerful type of ML loosely inspired by the brain, behind image recognition and language models.
• Frameworks: PyTorch (most common now), TensorFlow, scikit-learn (for classic ML).

Large language models (LLMs) and generative AI

• LLM (large language model): a model trained on huge amounts of text that can write, summarise and answer questions. Examples: OpenAI's GPT, Anthropic's Claude, Google's Gemini, Meta's Llama. At heart it's autocomplete on a massive scale: it predicts the next word extremely well.
• Generative AI (GenAI): AI that creates new content: text, images, code, audio.
• Prompt engineering: writing clear instructions to get good results from an LLM. Like briefing a very capable new assistant.
• RAG (retrieval-augmented generation): giving the AI an open-book exam. Before answering, it looks up the company's own documents, so answers are based on real, current information rather than memory.
• Vector database (Pinecone, Weaviate, pgvector): a library organised by meaning rather than alphabet, used to find the right documents for RAG.
• Fine-tuning: extra specialist training of an existing model on a company's own examples, like sending a graduate on a specialist course.
• Evals (evaluations): marking the AI's homework. Systematic tests of whether its answers are accurate, safe and useful. Serious AI teams talk about evals a lot.
• Agents: AI that doesn't just answer but takes actions, such as searching, filling in forms, booking meetings or writing and running code, working through a task step by step.
• Hallucination: when an AI confidently makes something up.
• MLOps / LLMOps: the DevOps of AI: deploying, monitoring and updating models reliably.

The roles

Recruiter tip: this is the hottest and most title-inflated area of tech. Ask for shipped, in-production AI features with real users: "How many users? How did you measure whether the AI's answers were good? What went wrong and how did you fix it?" Courses, certificates and weekend demos are a start, not proof.

2.12 QA, security, embedded and other engineering roles

QA and test engineering: the health inspector

• Manual QA / Test Analyst: tests the product by hand, following written test cases, and reports bugs. Increasingly rare as a standalone role.
• Automation QA / SDET (Software Development Engineer in Test): writes code that tests code automatically, so thousands of checks run in minutes on every change. Tools: Selenium, Cypress, Playwright, Appium (mobile), Postman (for APIs), JMeter / k6 (load testing: simulating thousands of users at once).
• The testing pyramid: lots of small, fast unit tests (checking one ingredient), fewer integration tests (checking ingredients work together in a dish), and a small number of slow end-to-end tests (checking a full meal from order to table).

Security engineering: the guards, locks and alarms

Certifications matter more in security than anywhere else in tech. Many security roles also need security clearance (SC, DV in the UK) for government and defence work, which can take months and affects who you can submit.

Embedded and firmware: software inside physical things

Embedded engineers write software that runs inside devices: cars, pacemakers, washing machines, drones, smart meters. The computer is tiny, memory is scarce and mistakes can be physically dangerous. Languages are mostly C and C++, increasingly Rust. Words you'll see: RTOS (real-time operating system), microcontrollers, firmware, IoT (Internet of Things: everyday objects connected to the internet). Many have electronics or electrical engineering degrees. This is a very different talent pool from web engineers.

Other roles you'll meet

• Game developer: usually C++ with Unreal Engine, or C# with Unity.
• Blockchain / Web3 engineer: builds on blockchains; language Solidity for Ethereum smart contracts.
• Solutions Engineer / Sales Engineer / Pre-sales: technical experts who help sell the product to customers through demos and technical answers. Part engineer, part consultant.
• Developer Advocate / DevRel: engineers who teach and inspire other developers to use a company's product (talks, tutorials, community).
• Solutions Architect / Enterprise Architect: design how large systems fit together across a company, often in consultancies and big enterprises.
• Engineering Manager: manages engineers (people, hiring, performance, delivery). Usually a former engineer, coding little or not at all.
• Forward Deployed Engineer: an engineer who works directly with customers to get the product working in their environment. Increasingly common at AI companies.

Recruiter takeaway for 2.10–2.12: the specialist roles are where titles are least reliable. For data, ask what last quarter's work looked like. For AI, ask what's in production. For security, check certifications and clearance early. For embedded, remember it's a separate talent pool.

2.13 Programming languages decoded

You don't need to know how to use these languages. You need to know what each is mainly used for and which ones are close relatives, so you can widen a search without making a bad match.

The transferable-skills cheat sheet

Three traps to remember:

1. Java is not JavaScript. As different as car and carpet.
2. Same language, different job. A Python data scientist and a Python backend engineer have very different skills. Always ask what the language is used for.
3. "Years of X" is a weak filter. Strong engineers learn a new language in weeks. Ask hiring managers: "Would a great engineer in X who is keen to learn Y work?" It often doubles your pool.

2.14 How engineers work day to day

Git and GitHub: version history for code

You know how Google Docs keeps a full version history, so you can see who changed what and undo mistakes? Git does that for code, for a whole team at once. GitHub, GitLab and Bitbucket are websites where teams store their code using Git.

• Repository (repo): the folder holding all of a project's code and its history.
• Commit: saving a change with a short note ("Fix checkout total rounding").
• Branch: a copy you can experiment on without touching the real thing, like duplicating a document to try a rewrite.
• Pull request (PR) / merge request (MR): asking to merge your branch back into the real thing. It's like submitting your edits with tracked changes.
• Code review: teammates read the pull request, comment, ask for changes and approve. This is how quality is kept high and knowledge is shared. Seniors spend a lot of time here.
• Merge: accepting the change into the main code.

Environments: rehearsal vs the live show

"Broke prod" means broke the live product for real users. That's why teams test so carefully before releasing.

Releasing safely

• Deploy / release / ship: putting a change live.
• Feature flag: a light switch that turns a feature on or off for some users, without releasing new code.
• Canary release: releasing to a small group first (like the miner's canary) and watching for problems.
• Rollback: undoing a release that went wrong.
• Hotfix: an urgent fix rushed out for a live problem.

Bugs, debt and renovations

• Bug: something that doesn't work as intended. Debugging is detective work to find the cause.
• Technical debt: shortcuts taken to move fast that make later work slower, like never tidying your kitchen. Eventually you can't cook. Teams regularly "pay down" tech debt.
• Refactoring: reorganising code to make it cleaner without changing what it does. Like renovating a house while people still live in it.
• Legacy code: old code that still runs the business but is hard and risky to change. "Modernising a legacy system" is common, valuable, often unglamorous work.
• Documentation: written explanations of how things work, for teammates now and in the future.

Agile in one paragraph

Most teams work in sprints (usually two-week cycles) using Scrum or Kanban (see Module 5), tracking tasks in Jira or Linear. Each piece of work is a ticket or user story; effort is estimated in story points (a rough size, not hours).

2.15 Architecture and system design concepts

Architecture is the overall shape of a system: which parts exist and how they talk to each other. Like a building's architecture, it's hard and expensive to change later, so senior engineers spend a lot of time on it.

System design is planning that shape for a new or growing system. It's a standard interview stage for mid-to-senior engineers: "Design a system like Uber / WhatsApp / a URL shortener." The interviewer is looking for how candidates think about scale, trade-offs and failure, not one right answer.

The ideas that come up again and again:

• Scalability: can it grow? (A corner shop vs a supermarket chain.)
• Reliability / resilience: does it keep working when parts fail? (A hospital's backup generator.)
• Performance / latency: is it fast?
• Security: is it safe from attackers and leaks?
• Maintainability: can other engineers understand and change it easily?
• Cost: what does it cost to run? Cloud bills can be huge.
• Trade-offs: you can't maximise everything. Faster usually costs more; simpler often scales less. Good engineers talk in trade-offs. If a candidate says "we used X because it's the best", that's weaker than "we chose X because of Y, accepting the downside Z".
• Distributed systems: systems spread across many computers. Powerful, but they fail in complicated ways. Experience here is a sign of seniority.
• Event-driven architecture: parts of the system react to events ("order placed") announced on a message bus, instead of calling each other directly. Like a shop tannoy: whoever cares about the announcement acts on it.

2.16 Worked example: decoding a job spec line by line

Here's a realistic job spec. On the right is what each line really means and what to ask.

Senior Backend Engineer, Payments (fintech scale-up, London, hybrid)

What you now know: the true must-haves are senior backend experience in a Java-like language, building systems at scale, and mentoring. Kafka, payments and Kubernetes depth are likely negotiable. That's a much bigger pool than the spec implies.

2.17 Worked example: decoding a CV

Software Engineer II, ShopCo (e-commerce, \~800 staff), 2022–present

• Owned the checkout service (Node.js/TypeScript, PostgreSQL, AWS Lambda), handling \~50k orders/day
• Led migration from a monolith to three services; cut checkout errors by 38%
• Introduced contract tests and feature flags; deploys went from weekly to daily
• Mentored two junior engineers; ran the team's on-call rota

Reading it like a pro:

• "Software Engineer II" sounds junior, but at many companies it's mid-level, and the content reads mid-to-senior. Judge by scope, not title.
• "Owned the checkout service": real ownership of a business-critical system. Strong.
• The stack: backend-leaning Node.js/TypeScript, a SQL database, and AWS Lambda ("serverless": running code in the cloud without managing servers yourself). Good fit for Node or Python backend roles; possible for Go with interest.
• "\~50k orders/day": meaningful scale. Ask about peak traffic.
• "Led migration... cut errors by 38%": architecture experience and a measurable result. A senior signal.
• "Contract tests and feature flags... weekly to daily": cares about quality and modern release practices.
• "Mentored two juniors; ran on-call": leadership beginnings and reliability maturity.

Verdict: a strong mid-level engineer edging into senior, backend-leaning. Questions to ask: How much frontend? What was their part of the migration versus the team's? Peak traffic? Why move now?

2.18 What separates a great engineer from an average one

The technical interview assesses coding skill. Here's what you can spot in a 30-minute call:

Engineering seniority in practice

2.19 Module 2 cheat sheet

Keep this one-glance summary open during calls.

Recruiter takeaway

For every engineering role, pin down five things in the intake:

1. Where in the restaurant? Frontend, backend, full-stack, mobile, platform, data or ML?
2. Must-have vs nice-to-have technologies, and which close relatives are acceptable.
3. Scale: users, data, traffic.
4. Level: by scope (Module 7), not years.
5. Practicalities: on-call, office days, and what each interview stage tests.

Then, on every candidate call, ask them to explain their current work as if you're not technical. You'll learn something new every time, and the best engineers will stand out immediately.