Understand hard things.

What amalgamation really means

When two companies join into one, the exam does not want your opinion. It wants a fixed set of steps, done in the right order. Learn the steps once, and every amalgamation sum turns into the same sum wearing new numbers.

Amalgamation is when two or more companies combine into one. The company that closes down and hands over its business is the transferor (you will also see it called the vendor company). The company that takes the business over, or the brand-new company formed to hold it, is the transferee (the purchasing company). That is the whole cast: one company handing over, one company receiving.

Now the natural question: why would companies do this at all? To grow faster, to cut duplicate costs, to end a price war, or to rescue a weak company by folding it into a strong one. That is the real-world why. But in your exam it always arrives the same way: you are given the two companies' balance sheets and the terms of the deal, and you are asked to pass the entries and draw the new balance sheet. Every amalgamation question, however long, is really just that one task.

So the method is fixed, but before you pass a single entry there is one decision that quietly controls the whole answer. Miss it and everything after is wrong. Let us meet it.

First, spot that it is an amalgamation sum

Recognising the method is half the marks. The moment a question says two companies combine, or one is taken over, or a new company is formed to absorb others, you are in amalgamation. The words to watch for are unmistakable once you know them.

You will meet three names for what is really the same thing. Absorption is when an existing company takes over another. Amalgamation (in the strict sense) is when a brand-new company is formed to take over two or more. External reconstruction is when a new company is formed to take over a single struggling company. The good news, and the reason this is one method and not three: you solve all of them with the exact same steps.

So whichever name the paper uses, your hands do the same thing. And the first move is always the same single decision.

Step 0: merger or purchase?

AS 14, the accounting standard that governs this topic, splits every amalgamation into just two types, and the type decides which method you use to record it. This is the most important line in the whole chapter. Decide it first, write it down, and only then start.

An amalgamation is "in the nature of merger" only if it passes all five tests. If even one test fails, it is "in the nature of purchase". There is no in-between.

Here are the five tests, in plain words. One: all the assets and liabilities of the transferor become the assets and liabilities of the transferee. Two: shareholders holding at least ninety percent of the face value of the transferor's equity shares become shareholders of the transferee. Three: the payment to those shareholders is made only in equity shares of the transferee (a little cash is allowed just for fractional shares). Four: the transferee intends to carry on the same business. Five: the transferee records the assets and liabilities at their existing book values, changing nothing except to line up accounting policies.

You have made the big decision. Whichever type it is, the very next thing you always compute is a single, all-important number.

Step 1: find the purchase consideration

The purchase consideration (PC) is what the transferee pays to the shareholders of the transferor, in the form of shares, other securities, and cash. Read that again, because one word carries most of the marks: it is paid to the shareholders, not to the creditors and not to the debenture-holders. Amounts the transferee pays to settle those outside claims are handled separately; they are never part of PC.

There are two ways to find PC, and which one you use depends only on what the question hands you.

The net payments method: simply add up everything the transferee gives the transferor's shareholders, the value of equity shares issued, plus any preference shares, plus cash, plus other securities. Use it when the question tells you what each class of shareholder receives.

The net assets method: take the agreed value of the assets taken over and subtract the agreed value of the liabilities taken over. What is left is the PC. Use it when the question does not spell out the payouts but does give you the values of assets and liabilities.

With the PC in hand, the transferor company can now be closed down properly. There is one account that does all of that closing work.

Step 2: close the seller's books

The transferor is shutting down, so its books must be closed cleanly. The single tool for this is the Realisation Account. Everything the company owned and everything it owed is passed through this one account, and whatever is left over at the end is the profit or loss the company made on selling its whole business.

The entries always run in the same order. First, transfer all the assets to the Realisation Account at their book value. Next, transfer all the outside liabilities into it. Then record the PC as due from the transferee, and record it being received (as shares and cash). Pay off anything the transferee did not take over, and record any realisation expenses. Finally, hand over the accumulated reserves and profits to the shareholders, settle the preference shareholders, and transfer the leftover balance of the Realisation Account, the profit or loss, to the equity shareholders.

The seller's books are closed. Now the buyer must bring the business onto its own books, and this is exactly where the merger-or-purchase decision finally changes the numbers.

Step 3: the buyer's entries

Same purchase consideration, two different ways to record the business, depending on the type you decided back in Step 0. This is where being right about merger versus purchase pays off.

Under pooling of interests (used for a merger), you bring in the assets, the liabilities and the reserves at their existing book values. Nothing is revalued. No goodwill and no capital reserve appear. If the PC does not match the transferor's share capital, the difference is simply adjusted against the reserves.

Under the purchase method (used for a purchase), you bring in the assets and liabilities at their agreed values. The transferor's reserves are not carried forward; their identity is lost, with one legal exception you will meet in a moment. And the gap between the PC and the net assets taken over becomes either goodwill or capital reserve.

So how do goodwill and capital reserve arise? Compare the PC with the net assets taken over. If the PC is more than the net assets, the buyer paid extra, and that extra is goodwill, shown as an asset. If the PC is less than the net assets, the buyer got a bargain, and the difference is a capital reserve.

Now the one legal exception. Some reserves are required by law, called statutory reserves, and they must survive even a purchase. To keep them, the buyer debits an Amalgamation Adjustment Account and credits the statutory reserve. That adjustment account then sits on the assets side of the balance sheet, and it is written back later when the statutory reserve is no longer required.

One last detail on goodwill. Goodwill arising on an amalgamation is not kept forever; AS 14 expects it to be written off (amortised) over its useful life, and normally that life is taken as a short period, not more than five years unless a longer life can be justified.

Assets are in, liabilities are in, goodwill or capital reserve is settled. Only one step remains: show the finished picture.

Step 4: the balance sheet after amalgamation

Finally, prepare the transferee's balance sheet after the takeover, in the Schedule III format. Add the taken-over assets and liabilities to the transferee's own. Put the newly issued shares under share capital, goodwill (if any) under non-current assets, and capital reserve (if any) under reserves. Then check the one thing that must always be true: it balances.

That is the whole method, one step at a time. Now let us run it once from start to finish on a real, small problem, so you can see the four steps click together.

The method, start to finish

A Ltd is taken over by B Ltd. A Ltd's summarised balance sheet shows sundry assets of 8,90,000, and on the other side equity share capital 5,00,000, reserves 1,40,000, and creditors 2,50,000. B Ltd takes over all the assets (agreed value 8,50,000) and the creditors (2,50,000), and pays the shareholders by issuing 50,000 equity shares of 10 each at 12, plus 50,000 in cash. It fails a merger test (cash is paid), so this is a purchase.

Notice how each step stood on its own and earned its own marks. The purchase consideration was one mark-earning working, the Realisation Account another, the goodwill calculation another. The final balance sheet was almost the easy part, just placing numbers you had already found.

Where students lose marks

None of these are hard once you have seen them. Everyone mixes up the purchase consideration exactly once, feels silly, and then never does it again. Work three full problems and the whole method turns automatic.

Bringing it all together

Here is the entire method in one breath. First decide merger or purchase by the five conditions. Then find the purchase consideration, by net payments or by net assets. Then close the seller's books through the Realisation Account. Then record the business in the buyer's books, book values for a merger or agreed values for a purchase, raising goodwill or capital reserve and preserving statutory reserves where needed. Finally, present the combined balance sheet in Schedule III format. Five moves, always the same, whatever the numbers.

If the exam asks you

What a cash flow statement really shows

A profit figure can smile at you while the bank account quietly empties. The cash flow statement is the exam's way of asking one blunt question: where did the money actually come from, and where did it actually go? Learn the three buckets and the fixed steps once, and every cash flow sum becomes the same sum wearing new numbers.

A cash flow statement tracks the real movement of cash into and out of a business over a year. Profit is an opinion shaped by accruals and estimates; cash is a fact. A company can report a healthy profit and still run out of money, because profit counts a credit sale on the day it is made, while cash only counts on the day the customer actually pays. This statement strips all that away and follows the cash itself.

Now the natural question: why split it into three parts at all? Because the reader wants to know not just how much cash moved, but what kind of activity moved it. Cash earned by running the business day to day is very different from cash raised by borrowing, or cash spent on buying a factory. AS 3, the accounting standard that governs this topic, sorts every cash movement into three activities, operating, investing, and financing, so the picture tells a story and not just a total.

So the whole statement is those three buckets, filled in a fixed order and then added up. Before we fill them, we should be able to recognise the question the moment it appears.

First, spot a cash flow question

Recognising the method is half the marks. The moment a question hands you two balance sheets, one at the start of the year and one at the end, along with some profit details, and asks you to prepare a statement of cash flows, you are in AS 3 territory. Two balance sheets always come together for a simple reason: cash flow is about the change over the year, so you need a before picture and an after picture, and almost every figure you need is hidden in the difference between them.

Your real job, then, is to read those differences correctly and drop each one into the right bucket. That single act, dropping each item into the right bucket, is where the marks live and where students slip. But before any of that, there is one small decision to make.

Step 0: pick the method

AS 3 lets you find the operating cash figure in two ways, the direct method and the indirect method. They differ only in how they compute the first bucket, operating activities; the investing and financing buckets are identical either way. So the choice is really just about that one section.

The direct method lists the actual cash received from customers and the actual cash paid to suppliers and staff. It is clean to read but needs data the question rarely gives in full. The indirect method starts from the net profit before tax and works backwards, undoing every non-cash and non-operating item until only real operating cash is left. Because the exam usually gives you profit figures and balance sheets, not a cash book, the indirect method is the one ICAI expects and the one nearly every problem is built for.

Method chosen, we start filling the first and largest bucket, the one that carries the most marks and the most traps.

Step 1: cash from operating activities

Operating activities are the main, everyday, revenue-earning things the business does, selling goods, paying suppliers, paying staff. Under the indirect method you do not track those cash movements directly; instead you begin with the net profit before tax and carefully turn that accounting profit back into cash.

The first move is to add back everything that reduced profit but never actually moved any cash, and to strip out anything that belongs to another bucket. Depreciation is the classic one: it was subtracted to reach profit, but no cash left the business, so you add it back. Same with a loss on sale of an asset, and goodwill or preliminary expenses written off. You also add back interest expense, because that cash outflow belongs to financing, so you remove it here and deal with it there. By the same logic you subtract non-operating incomes like interest and dividend received, because they belong to investing.

After those add-backs you have a figure called operating profit before working capital changes. But you are not done, because profit still ignores one thing cash cares about deeply: whether your customers have actually paid you, and whether you have actually paid your suppliers. That is the working-capital adjustment, and it is where most marks are won or lost.

Here is the logic, and it is worth slowing down for. If your debtors go up over the year, more sales are still stuck as unpaid bills, so cash has not come in; more money is tied up. An increase in any current asset is therefore an outflow. Flip it around: if your creditors go up, you are holding on to cash you owe but have not yet paid, so the cash has effectively stayed with you. An increase in any current liability is an inflow.

Once working capital is adjusted you reach cash generated from operations. One last step: subtract the income tax paid during the year. Tax paid is treated as an operating outflow, unless the question clearly links it to investing or financing. After deducting it you finally have net cash from operating activities, the whole first bucket, done.

The big bucket is full. The next two are shorter and calmer, because there are no adjustments, just a clear list of what belongs in each.

Step 2: cash from investing activities

Investing activities are about the long-term assets of the business, the things it buys to use for years, not to resell. So this bucket holds the cash spent on buying fixed assets like land, buildings, and machinery, and the cash received from selling them. It also holds the purchase and sale of investments, the shares or debentures of other companies held for the long term.

Two incomes live here too, for a normal non-financial company: the interest received and dividend received on those investments. The idea is that these returns flow from assets the business invested in, so the cash they bring belongs with investing. Add up the inflows, subtract the outflows, and you have net cash from investing activities, usually a negative number for a growing company, because a growing company keeps buying assets.

That leaves the third bucket, the one about where the company's money comes from in the first place, and who it pays back.

Step 3: cash from financing activities

Financing activities are about the providers of money, the owners and the lenders. When the company raises cash by issuing shares or issuing debentures, that is a financing inflow. When it returns cash by redeeming debentures, buying back shares, or repaying long-term loans, that is a financing outflow. Two payments that trip people up also sit here for a non-financial company: dividend paid to shareholders and interest paid on borrowings, because both are the cost of the money the company raised. This is exactly why, back in Step 1, you added interest expense back to profit, so you could show it cleanly here instead.

You have now seen where each item goes. But a few items, especially interest and dividend, could plausibly sit in more than one bucket, so let us pin the rule down properly.

The classification decision: which bucket?

Most items announce their bucket loudly, a machine purchase is obviously investing, a share issue is obviously financing. The four that cause real hesitation are interest and dividend, both paid and received. For a normal non-financial company, AS 3 fixes them clearly, and this is worth memorising cold.

So, for an ordinary company: interest received and dividend received go to investing, as returns on money you invested; interest paid and dividend paid go to financing, as the cost of money you raised. Four items, two simple homes: money coming in from your investments, money going out to your financiers.

With every item now in its right bucket, only the finishing move remains, adding the three buckets up and proving the answer is correct.

Step 4: net change and the reconciliation

Add the three buckets together, operating plus investing plus financing, and you get the net change in cash and cash equivalents for the year. It can be positive, cash grew, or negative, cash shrank. Then add the opening balance of cash and cash equivalents, and the result must equal the closing balance.

That last equality is not just arithmetic, it is your built-in proof. The closing figure you calculate must match the cash and bank balance shown in the closing balance sheet. If it does, your statement is almost certainly right. If it does not, you have misclassified or missed an item, and you go back and hunt for it.

That is the entire method, four steps and a proof. Now let us run it once, start to finish, on a small company so the pieces click together.

The method, start to finish

Here is XYZ Ltd. You are given its balance sheet at the start and end of the year, plus a few notes, and asked to prepare the cash flow statement by the indirect method. First, know the shape you are filling in, then read the data once, because every number in the answer comes from it.

Start by rebuilding the net profit before tax, because the question hides it inside the reserves. The retained profit rose by 30,000; add back what was taken out of profit during the year, the transfer to reserve, the dividend, and the tax provision, and you have the profit the year actually earned before tax.

One working hides inside investing, the fixed assets purchased. The net block rose by 1,00,000, but 50,000 of depreciation was also charged during the year, so the actual cash spent buying assets was 1,00,000 plus 50,000, that is 1,50,000. Always add the year's depreciation back to the rise in the net block to find the true purchase.

Look what happened at the end: the closing figure came to 35,000, exactly the cash and bank shown in the 2024 balance sheet. That match is the proof that every item landed in the right bucket. Notice too how each step earned its own marks, the profit working, the operating section, investing, financing, each one a separate, labelled block the examiner can reward on its own.

Where students lose marks

None of these are hard once you have seen them. Everyone reverses the working-capital sign exactly once, feels silly, and then never does it again. Work three full problems and the whole method turns automatic.

Bringing it all together

Here is the entire method in one breath. Pick the indirect method. Build the operating bucket by starting from net profit before tax, adding back non-cash and non-operating items, adjusting for working-capital changes, and subtracting the tax paid. Build the investing bucket from purchases and sales of long-term assets and the interest and dividend received. Build the financing bucket from shares and debentures raised or repaid, and the interest and dividend paid. Add the three, add opening cash, and prove that you land on the closing cash in the balance sheet. Four steps and a proof, always the same, whatever the numbers.

If the exam asks you

Right now, without you doing a single thing, your body is fighting off germs. It has been all day. You have a defence system so good that you almost never notice the battles it wins.

A fortress under constant siege

Germs are everywhere, on your hands, in the air, on everything you touch. Most of them would love to get inside you and multiply. The reason you are not sick all the time is that your body guards itself every second of every day.

It does this with two teams. One is a fast, general guard that attacks anything suspicious on sight. The other is a slow, brilliant specialist that studies one exact enemy and then never forgets it. Together they are called your immune system.

The first wall: skin and slime

Before any germ can cause trouble, it has to get in. And getting in is hard. Your skin is a tough, unbroken wall wrapped around your whole body, and germs simply cannot walk through it.

The soft openings, your eyes, nose, and mouth, cannot be covered in skin, so they are guarded differently. Tears wash the eyes, sticky mucus traps germs in the nose, and strong acid in the stomach dissolves most of what you swallow.

There is even more to the wall than that. The mucus in your airways is swept along by millions of tiny hairs called cilia, carrying trapped germs back up and out. Your tears and saliva also carry a germ-dissolving substance called an enzyme. The body layers defence on defence.

The first responders: cells that eat germs

Say a germ does get in through a cut. Alarms go off, and special white blood cells rush to the spot. Some of them do something amazing: they surround the germ and swallow it whole, then digest it. They literally eat the enemy.

This fast, general defence is called innate immunity. It does not care which germ it is, it attacks anything foreign, and it does so within hours. The eating cells have names worth knowing: neutrophils, which arrive first in huge numbers, and macrophages, a word that means "big eaters".

This is also why a small infected cut turns red, warm, and a little swollen. That is not the germ doing damage, it is your body rushing extra blood and extra fighter cells to the exact spot. The name for it is inflammation.

A fever works the same way, on purpose. When your body raises its own temperature, it slows many germs down and speeds your own defenders up. The uncomfortable heat is a weapon, not the illness itself.

The specialists: an army built for one enemy

Sometimes the fast guards are not enough, and the germs start winning. That is when the second team wakes up: the specialists. They are slower to get going, taking days, but they are precise, and they aim at one exact germ.

Their main weapon is the antibody. An antibody is a tiny Y-shaped tag that locks onto one specific germ and marks it, like painting a target on it, so the rest of the body knows exactly what to destroy.

Each antibody fits its germ the way one key fits one lock. The bump it locks onto is called the germ's antigen, its marker. The cells that make antibodies are B cells. They get help from T cells: helper T cells coordinate the whole attack, and killer T cells destroy your own cells once a germ has hidden inside them.

The part that changes everything: memory

Once the specialists win, they do not just pack up and leave. They keep a few memory cells on duty, cells that remember that exact germ forever.

So the next time the very same germ appears, the response is not slow at all. The memory cells recognise it instantly and crush it before it can grow. You never even feel sick. You have become immune to it.

This memory is exactly why some illnesses, like chickenpox or measles, usually strike a person only once in a lifetime. After the first fight, your body is ready forever, and the germ never gets another chance.

The clever trick: vaccines

Here is the beautiful idea humans discovered. If memory is what protects you, what if you could build the memory without having to suffer the illness first? That is exactly what a vaccine does.

A vaccine shows your immune system a harmless preview of a germ, a dead or weakened piece of it. Your body treats the preview as a practice enemy, makes antibodies, and stores memory cells, all without you ever getting the real disease.

The preview carries the germ's marker, its antigen, but it cannot make you ill. Your specialists practise on it, build their antibodies and memory cells, and stand ready. If the real germ ever arrives, it walks straight into an army that already knows its face.

When the guard makes a mistake

A defence this powerful can sometimes get confused, and it helps to know how. Occasionally the immune system attacks something harmless, like pollen or peanuts, and that overreaction is what we call an allergy.

More seriously, it can sometimes turn on the body's own healthy cells by mistake, which is called an autoimmune condition. Understanding and calming these mistakes is one of the biggest jobs in modern medicine.

If someone asks you

The whole idea

Your body defends itself in layers. A tough wall of skin keeps most germs out. Fast eater cells swallow the ones that break in. If those are not enough, precise specialists make antibodies aimed at one exact germ, and then leave memory cells behind so it can never hurt you the same way twice. Vaccines simply teach that memory safely, in advance. You were never as fragile as you felt, you are a fortress that heals, learns, and remembers.

What is programming?

Before Python, let’s look at the big picture. It makes everything after this much easier.

A computer is very fast and never gets tired. But it has one funny weakness: it cannot guess. It only does what you tell it, in the exact order you tell it. So programming just means writing a list of clear steps for the computer to follow, one line at a time, from top to bottom. That finished list of steps is what we call a program.

Why do we do this? Because once you write the steps well, the computer will repeat them perfectly a million times and never get bored — adding up numbers, saving customer details, showing a website to people all over the world. You write it once, and the computer does the boring work again and again.

And where do we see this? Everywhere. The app on your phone, the website you opened this morning, the bill screen at a shop, the system that runs YouTube. Each one is just a program quietly following its steps. To write them, we use a programming language — a way of writing that sits between human language and computer language. The one you are here to learn is called Python.

What is Python?

Python is a programming language, and a very friendly one. Let me explain what “friendly” really means, because it is more than a nice word.

Python was made to read almost like simple English. When you write Python to check someone’s age, it looks like if age > 18: — you can almost read it out loud. Many older languages made you write pages of confusing setup just to do something small. Python does the opposite: keep it simple, keep it easy to read, and let you think about the idea instead of fighting the computer.

Who made it, and why? It was made by Guido van Rossum, and it first came out in 1991. Fun fact: the name has nothing to do with the snake — he named it after the comedy group Monty Python, because he wanted the language to feel light and fun. That spirit still holds: Python is here to make coding easy and quick, so you spend your time solving the real problem.

So where do people use Python? The engine behind Instagram and YouTube uses a lot of Python. It is the number-one language for artificial intelligence and data work. And — this is your area this week — it is a favourite for building web services, the servers and apps that power the internet. The job you are getting ready for sits right inside Python’s strongest area.

It is only fair to say what Python is not great at, because a good developer knows both sides. It runs a little slower than heavy languages like C++ when you crunch huge amounts of numbers, and it is not the tool people pick to build phone apps or the visual part of websites. But for backends, data, and AI, it is a great choice.

One last note: there are two big versions, Python 2 and Python 3. Python 2 is old and finished, so skip any tutorial that uses it. You will use modern Python 3 — the newest today is the 3.14 series, but anything 3.10 or newer is perfectly fine for learning.

If you see something like Python 3.12 or Python 3.14, you are ready. (If it is missing, install it from python.org and check again.) Now make a folder and your first file:

Create a file called hello.py with this one line inside, then run it:

Whatever you wrote inside the quotes shows up on your screen. Enjoy that for a second — you just told a computer to do something, and it listened. The word print is a step that means “show this on the screen,” and the computer read your file top to bottom and followed it. That, in small form, is all that programming is.

Variables: how Python remembers things

Here is a question to think about. Your hello.py showed some text and then forgot all about it. But useful programs need to remember things — a user’s name, the total in a cart, whether someone is logged in. So how does a program hold on to a piece of information so it can use it again later?

The answer is a variable. A variable is just a name you give to a value, so you can use it again whenever you want. You already do this in real life: you do not remember your mother’s phone number digit by digit — you save it under the name “Mom” and tap that name. The number is the value; “Mom” is the variable.

In Python it looks like this:

That little = gives beginners a wrong idea, so let me fix it now. It does not mean “equals” the way it does in maths. It means “take the value on the right, and store it under the name on the left.” So age = 21 reads as “let age hold 21 from now on.” And because it is just a holding spot, you can change what is inside it any time:

Data types: the kinds of values

You can store a value in a variable. But not all values are the same kind of thing, and Python quietly cares about that. The word “Aarav” is text. The number 21 is a number. “Is this user active?” is really just a yes or no. Each is a different type, and the type matters because it decides what you can do with the value. You can multiply two numbers, but multiplying two names makes no sense — and Python knows that.

There are a few basic types you will use all the time:

Here is something interviewers love to ask. Notice you never told Python what type each variable would be. You just wrote age = 21 and Python looked at the value and worked out the type by itself. This is called being dynamically typed. In some languages, like Java or C++, you must say the type first, like int age = 21 — that is called statically typed. Python is the easy, flexible kind: give it a value and it figures out the rest. You can even put a number in a variable today and text in it later, and Python will not stop you. The small catch: because Python does not check types ahead of time, some type mistakes only show up when the program runs — so stay a little careful.

Why care about these names? Because many real bugs come from mixing them up. The most common one is text that looks like a number. When a user types their age on a website, the computer gets it as text — the characters “2” and “1” — not the number 21. If you do maths on it directly, Python complains. So you change it first:

This happens the moment you work with web forms, which is why we meet it early. Where you feel types most is with text, because web work is full of it. Python gives you nice little tools for text:

And there is a clean, modern way to build a sentence with variables inside it, called an f-string. Put an f just before the opening quote, and wrap any variable in curly braces:

You will use f-strings all the time, so get used to them now.

Operators: maths and making checks

Once you have values, you want to do things with them — add them up, compare them, combine yes/no answers. The little symbols that do this are called operators.

The maths ones work just as you expect, with two that surprise people:

That % (remainder) is the easy way to check if a number is even or odd — an even number divided by 2 leaves a remainder of 0.

Next are comparison operators. They ask a yes/no question and hand back True or False:

Last are logical operators — and, or, not — which combine yes/no answers. You will use these constantly inside if conditions:

Making choices with if

So far your programs run straight down, doing the same thing every time. But think about an ATM. If your balance is enough, it gives you the cash. If not, it shows an error. It chooses based on the situation. That power to choose is what turns a plain list of steps into something useful, and in Python we do it with the word if.

Read it almost like English: if the withdraw amount is less than or equal to the balance, print one thing, or else print another. Two things in that code are new. First, the colon : at the end of the if line. Second — and this matters in Python — the line under it is indented, pushed in by four spaces. That spacing is not just for looks; it is how Python knows which lines belong inside the if. Other languages use curly brackets; Python uses the spacing itself. Get it wrong and Python will stop and complain, so build the habit from day one.

Often you have more than two paths — say, turning a score into a grade. For that you join checks with elif, short for “else if”:

Python reads these top to bottom and stops at the first one that is true. Since 78 is not 90-or-more but it is 75-or-more, it lands on “B” and skips the rest.

Loops: doing something again and again

Imagine you have a hundred customers and you want to greet each one. You are not going to write a hundred print lines. The whole point of computers is that they are happy to repeat boring work, and the tool that tells them to repeat is a loop.

The most common one is the for loop. You use it to go through a group of things one by one — picture a teacher reading every name on a register:

Read it as “for each name in this list, print a greeting.” Python takes the first name, runs the indented line, then the second, then the third, and stops when the list is over. (Notice the colon and the indented line again — same rule as if.) Sometimes you just want to repeat a set number of times. For that Python gives you range:

One small surprise: range(1, 6) stops before 6, so you get 1 to 5, not 6. Everyone forgets this once, then never again.

There is a second kind of loop, the while loop. It keeps repeating as long as a condition stays true — handy when you don’t know in advance how many times you’ll repeat, like asking until something is right:

Two handy words work inside any loop: break stops the loop completely, and continue skips the rest of this turn and jumps to the next one:

Holding many things: lists and dictionaries

So far each variable held one value. But real programs are full of groups of things — a list of users, a record with many details about one person. Python has a few ways to hold many things together; two matter most.

The first is the list — an ordered line-up of values, written inside square brackets:

Because it is ordered, you grab items by their position. Here is the one thing that surprises every beginner: counting starts at zero, not one. So the first item is at position 0:

And a list can change — that is the point of it:

The second one is the dictionary, and I want extra attention here, because it becomes the star once we reach web development. A list is great when order matters, but often you want to look things up by a name instead of a position. Think of an ID card with a “Name” field, an “Age” field, a “Course” field. A dictionary stores data exactly like that, as pairs of a label (a key) and its value:

Keep this shape in mind — { "key": value }. When we reach web services, the data that travels between an app and a server looks almost exactly like this. So a dictionary is the bridge to everything you build later this week.

There are two more groups worth knowing, and one is asked in almost every interview, so let’s do it properly. The first is the tuple. It looks almost like a list, but you write it with round brackets, and here is the big difference: once you make a tuple, you cannot change it — not add, not remove, not swap. It is locked.

This brings up a word interviewers love: mutable and immutable. Something that can be changed after you make it is mutable; something that cannot is immutable. A list is mutable; a tuple is immutable. That leads to the most common beginner question of all: “what is the difference between a list and a tuple?” The clean answer: both keep items in order, but a list can change and a tuple cannot. Use a list when data might change (a cart, a list of users), and a tuple when it should stay fixed (map coordinates, a date of birth).

The second is the set — a group that quietly throws away duplicates. Put the same thing in twice and the set keeps only one copy. Handy when you want a list of unique things, like the tags on a post:

Functions: write it once, use it forever

Here is a moment every programmer has. You write a few lines that work something out — say, a price with tax added — and then you need that same bit in five different places. You could copy-paste it five times, but if the tax rule ever changes, you must find all five copies and fix each one, and you’ll miss one. There is a better way: a function.

A function is a named, reusable block of steps. You write the logic once, give it a name, and call it by name whenever you need it. Think of a coffee machine: you don’t explain how to make coffee every morning — you press one button, maybe choose a cup size, and coffee comes out. The button is the function’s name, the cup size is the input, and the coffee is the result it gives back.

In Python you make one with the word def:

Let me walk through it: def starts the function, greet is the name we chose, the name in brackets is the input it expects (we call it a parameter), and return is how it gives a result back. Now you can use it as many times as you like:

One function, used twice, no copy-paste — and if you ever change how greetings work, you change it in one place. You can give a function more than one input, and even a default so an input becomes optional:

One last friendly thing: errors are normal

Before you go off and build, let me put your mind at ease, because this stops a lot of new learners. You are going to see red error messages. A lot of them. Every programmer does, all day, every day. An error is not you failing — it is Python being helpful, telling you exactly what confused it and where.

The trick is simple: read the last line of the error first, because that is the part that names the problem. For example, if you write "21" + 1, Python stops and says something like “can only join text to text” — its way of telling you that you tried to add a number to some text, and you just need to change one of them first.

When you think something might go wrong — like a user typing letters where you wanted a number — you can catch the problem nicely so your program does not crash:

You will learn more of these tricks as you go. For today, carry this idea: errors are guides, not judges.

Bring it all together

If the interview asks you

Say these out loud until they feel easy. Tomorrow: objects, and how the web really works.

What is object-oriented programming?

Until now, your data lived in variables and your actions lived in functions, and the two floated around separately. That is fine for small programs. But as programs grow, you end up with dozens of loose variables and functions, and it gets messy — like a kitchen where the ingredients and the tools are scattered all over the floor.

Object-oriented programming (people shorten it to OOP) is just a way to keep related things together. The idea: bundle some data and the actions that work on that data into one neat package, called an object.

Think about a car. It has data — its colour, brand, current speed. And it has things it can do — start, speed up, brake. It makes sense to keep those together, because “brake” acts on this car’s speed. OOP lets you model a real thing exactly like that. It matters because almost everything you touch this week — FastAPI, database models — is built this way.

Classes and objects

This is the heart of OOP, and the most common thing an interviewer asks, so let’s make it crystal clear. A class is a blueprint. An object is a real thing built from that blueprint.

Think of an architect’s plan for a house. The plan is not a house — you cannot live in it. But from one plan, a builder can make many real houses. The plan is the class; each real house is an object. One class, many objects.

Here is a car blueprint in Python:

Now build real cars from it:

Two new words to learn slowly, because they trip everyone up. __init__ is a special function that runs automatically the moment you create an object; its job is to set up the starting data. You never call it yourself — writing Car("Toyota", "red") runs it for you. People call it the constructor.

self means “this particular object.” When you write self.brand = brand, you store the brand on this specific car — that is how car1 and car2 each remember their own. Every method takes self first, so it knows which object it is working on.

Two more names: data on an object (like car1.brand) is an attribute; a function that belongs to an object (like car1.start()) is a method. Attributes are what an object has; methods are what it can do.

The four pillars of OOP

Interviewers almost always ask you to “name the four pillars of OOP.” They are four big ideas that make OOP powerful. Let’s take them one at a time, each with a little picture, so the why of each really sticks.

Encapsulation means bundle the data and methods together, and protect the data so outside code can’t mess it up directly — you change it only through safe methods. Think of an ATM: you press buttons, but you cannot reach in and change the cash count by hand.

You interact through deposit and get_balance, not by editing _balance. In Python, a name starting with a single underscore is a polite signal: “internal, leave it alone.” That is how Python marks something private.

Inheritance lets a new class reuse everything from an existing class and add its own extras. An “ElectricCar” is a kind of “Car” — it has everything a car has, plus a battery, so you inherit instead of copy-pasting.

Polymorphism means different objects respond to the same command in their own way. A dog barks, a cat meows — same speak() command, different result.

A common form is method overriding: a child class writes its own version of a method it inherited from the parent.

Abstraction means showing a simple way to use something while hiding the messy details — like a steering wheel (you turn it; you don’t manage the hydraulics). Calling account.deposit(500) hides all the checking inside: a clean outside, a hidden inside.

Splitting code into files: modules

As your program grows, you do not keep everything in one giant file — it becomes impossible to read. You split it into several files, and a single .py file you can use from another file is called a module.

Say you have math_helpers.py:

Use it from another file by importing it:

Python also ships with a big set of ready-made modules called the standard library — free, no install:

A clean workspace: virtual environments

Here is a real problem you will hit soon. Different projects need different outside libraries, sometimes different versions of the same one. If you install everything in one shared place, projects clash — one needs an old version, another a new one, and they fight.

The fix is a virtual environment: a clean, separate box of libraries for each project. Think of a separate toolbox per project, instead of one giant shared drawer. The tool that installs libraries is called pip. Here is the whole routine you’ll use all week:

That requirements.txt is a shopping list of your project’s libraries. Anyone (including future you) can recreate the exact setup with one command: pip install -r requirements.txt.

Now the web: clients and servers

We switch gears now — from organising code to understanding the internet, because the rest of this week is about building web services, and you cannot build one without this picture.

The whole web runs on two roles talking to each other: a client and a server. The clearest way to picture it is a restaurant. You, the customer, are the client — you place an order. The server is the kitchen: it receives your order, does the work, and sends back a dish. Your order is the request; the dish that comes back is the response.

A server, then, is simply a program that runs all the time, waits for requests, and sends back responses. That is the whole definition. When you open a website, your browser (the client) sends a request to a server; the server figures out what you want, maybe fetches some data, and sends back a response — a page or some data. This back-and-forth has a name: the request–response cycle. It is the loop you will build, piece by piece, this week.

HTTP: the language of the web

For the client and server to understand each other, they need an agreed language. That language is HTTP. It is just the agreed format for asking and answering on the web — like the rules of ordering politely at a restaurant.

Every request says two main things: which thing you want (a web address, called a URL, like /users/5) and what action you want. The action is an HTTP method (or verb). There are a handful you must know, and they line up perfectly with the four things you do with data, called CRUD — Create, Read, Update, Delete:

GET reads and should never change anything. POST creates something new. PUT and PATCH change something (PUT replaces the whole thing; PATCH changes a part). DELETE removes it. Tomorrow, in FastAPI, you’ll write one of these for each thing your app can do.

What is an API, and the parts of a request

You’ve heard the word API all week, so let’s pin it down. An API (Application Programming Interface) is the set of doors a server opens for other programs — each door a URL plus a method (an endpoint), with an agreed format for what you send and get back. When your front page or a mobile app talks to your server, it’s using your server’s API. It’s a contract: “send a request shaped like this, get back data shaped like that.”

So every HTTP request has four parts: the method (the verb), the URL (the address, with any query parameters), the headers (small bits of info about the request), and the body or payload (the data you send, usually JSON, mostly with POST and PUT).

Headers confuse people, so picture them as the writing on the outside of an envelope — not the letter, but details the post office needs. The common ones: Content-Type: application/json says “my body is JSON”; Authorization: Bearer <token> carries proof of who you are (more tomorrow); Accept and User-Agent say what format you want back and which app is asking. The response has headers too. So the round trip is: request (method + URL + headers + body) out, response (status code + headers + body) back.

What happens when you type a URL?

This question comes up in interviews all the time, because it shows whether you understand the web beneath your app. Let’s walk through what really happens between pressing Enter and seeing the page.

First, the browser has the name of a site like google.com, but computers find each other by numbers (IP addresses). So it asks a phone book called DNS to turn the name into a number. Then it opens a connection — a TCP handshake that sets up a reliable line (and a TLS handshake on top, for https, to lock it).

With the line open, the browser sends an HTTP request (usually a GET). The server — maybe a Python app with a database behind it — does its work and sends back an HTTP response: the page’s content plus a status code. Finally the browser renders it, turning HTML and images into the page you see. Submitting a form is the same story, just usually a POST carrying your data.

Status codes and JSON

Every response carries a little 3-digit status code — a quick way for the server to say how it went. The trick is the first digit: 2xx means success, 4xx means you (the client) made a mistake, 5xx means the server made a mistake.

Two that confuse people: 401 means “I don’t know who you are — please log in,” while 403 means “I know who you are, but you’re not allowed, and logging in again won’t help.”

When a server sends back data (not a whole page), it almost always uses a format called JSON. The lovely part for you: JSON looks almost exactly like a Python dictionary — the same braces, keys, and values from yesterday.

Python has a built-in tool to switch between a dictionary and JSON text:

Easy to remember: dumps dumps a Python object out into a string; loads loads a string back into a Python object. This is why dictionaries mattered so much yesterday — they are the shape of the data that flies between apps and servers.

The whole picture

Here is the journey of one click — the thing you are building towards all week:

A client sends an HTTP request, your server (FastAPI) receives it, the server talks to the database, gets the data, and sends a JSON response back to the client. That round trip is the frontend-to-server loop — the whole reason we are here. Today you learned the words for every arrow in this picture. Over the next three days, you’ll build each piece for real.

If the interview asks you

Tomorrow: we turn your Python into a real, running web server with FastAPI.

What is FastAPI?

FastAPI is a Python framework for building web services — servers that send and receive data, usually as JSON. That word framework matters: it’s a big box of ready-made tools that handles all the boring, hard, repetitive parts of a job, so you only write the part that is special to your app.

Why use one? Building a server from scratch means writing tons of low-level code — reading raw HTTP, checking every piece of data, formatting replies. FastAPI does all that for you. People love it for three reasons: it’s quick to write and quick to run, it checks incoming data automatically, and it builds you an interactive docs page for free.

So where is it actually used? It’s a top choice for modern Python backends — the services behind mobile apps and websites, the small fast “microservices” big companies run by the dozen, and especially the APIs that serve AI and machine-learning models. In short, exactly the work this week is preparing you for.

So how do you make one? Create a file main.py:

Run it with uvicorn main:app --reload — that says “in the file main, find app, and run it,” reloading when you change the code. Open http://127.0.0.1:8000 to see your JSON, then open /docs — FastAPI built you a full interactive testing page, automatically.

Decorators: the @app.get line

You just wrote a line starting with an @, called a decorator. It appears above every endpoint you’ll write, so let’s understand it. A decorator sits right on top of a function and adds extra behaviour to it, without changing the function’s own code.

Why does FastAPI use them? You need a clean way to say “when a request for this address arrives, run this function.” The decorator attaches that wiring neatly on top, keeping the function itself simple. You’ll see one above every route in every FastAPI app.

So how does it read?

Change the verb (get, post, put, delete) and the address, and you register a different endpoint. You don’t need to write decorators from scratch to use FastAPI — just know they attach behaviour to a function.

Path parameters: values in the address

Often the address itself carries a piece of data. /users/5 means “the user with id 5.” That 5 is a path parameter — a changing part of the address. Why put it in the address? Because it’s the clean, standard way to point at one specific thing. You’ll use it for every “get/update/delete one item” endpoint: /products/42, /orders/1001.

So how do you grab it?

The {user_id} in the address is a placeholder, and user_id: int says “grab that value, and it must be a whole number.” Visit /users/5 and you get it back. Now the lovely part: visit /users/abc and FastAPI automatically rejects it, because abc isn’t a whole number. You wrote zero checking code — the little : int did it, straight from the type hints you already know.

Query parameters: the part after the ?

Sometimes you’re not pointing at one specific thing — you’re adjusting a request, like filtering or searching. That’s what query parameters are for: the optional ?key=value bits at the end of an address, like /products?category=shoes&max_price=2000. You’ll see them on every search and listing page.

So how do you read them? Any function parameter that is not part of the path automatically becomes a query parameter:

Visit /products for the defaults, or /products?category=shoes&max_price=2000 for your values. Because each has a default, they’re optional.

Path vs query (a favourite interview question): a path parameter identifies one specific thing and is part of the address (/users/5), usually required. A query parameter filters or adjusts a request (/users?role=admin), usually optional.

Pydantic models (schemas)

This is the most important topic of the day, and almost certainly an interview question. When someone says “FastAPI models” or “schemas,” they mean Pydantic models. Here’s the problem they solve: for requests that send data — like creating a user with POST — the data arrives in the request body as JSON. You must receive it, check it has the right fields and types, and reject anything wrong. Doing that by hand, for every field, is slow and buggy.

So the fix: describe the shape of the data once, as a class, and FastAPI checks every incoming request against it. That class is a Pydantic model. You’ll write one for every endpoint that accepts or returns data.

When a request hits POST /users, FastAPI reads the JSON, checks it against User (are the fields there? is age a number?), and if anything is wrong it automatically returns a clear 422 error. If it’s good, you get a tidy user object. You can also shape what goes out — great for hiding things like passwords:

A full CRUD API

Now let’s combine everything. Remember CRUD — Create, Read, Update, Delete? We’ll build one endpoint for each, on a “notes” resource, storing them in a plain list for now (a real database is tomorrow).

And the update and delete endpoints follow the same shape, each finding the note by id and either changing it (PUT) or removing it (DELETE), raising a 404 if it isn’t found. Two things to name: HTTPException is how you deliberately send an error like 404, and status_code=201 means “created.” Each resource lives at one address and the HTTP method decides the action — that style is called REST.

Routers: splitting a big app

When your app grows past a few endpoints, you don’t keep them all in main.py — it becomes a mess. FastAPI gives you APIRouter to group related endpoints into their own files, then plug them into the main app. Why? So a real app with dozens of endpoints stays organised and teams can work in parallel.

Now /users/ works, but its code lives in its own tidy file. The prefix="/users" means every route in that file starts with /users, so you don’t repeat it.

Dependency injection: Depends

Here’s one more idea that sounds fancy but is simple. Often several endpoints need the same thing done first — open a database connection, or check the user is logged in. Why repeat that code everywhere? You don’t. FastAPI lets you write it once and “inject” it wherever needed, using Depends. You’ll use this most for database connections (tomorrow!) and login checks.

You declare that profile depends on get_current_user. FastAPI runs that first and passes its result straight in. The interview-ready line: dependency injection lets you reuse shared setup across many endpoints instead of repeating it, which keeps code clean and easy to test.

Authentication and tokens

So far, anyone could call your endpoints. Real apps need to know who is making each request — that’s authentication. Why? Because you don’t want a stranger reading someone else’s private messages or deleting their posts. The server needs proof of identity on every request.

So how is that proof carried, without resending your password each time? With a token. The user logs in once with a username and password; if correct, the server hands back a small signed string called a token (a common kind is a JWT). From then on, the app sends that token in the Authorization header you met yesterday — Authorization: Bearer <token>. The server checks it to know who you are.

Where does it live in FastAPI? In a dependency. You write a get_current_user that reads the token from the header, checks it, and returns the user — and any endpoint that needs a logged-in user just depends on it. That token="demo" placeholder from a moment ago stands in for this real check.

Why FastAPI is fast: async

A question that comes up in nearly every FastAPI interview: why is it fast? A big part of the answer is a feature called async. Normally code runs one line at a time, and when it hits something slow — like asking the database for data — it just waits, doing nothing. For one user that’s fine. But a server handles many people at once, and if every request freezes while waiting, everyone queues behind it.

So async lets your server start a slow task and, instead of freezing, handle other requests while it waits — then pick it back up when it’s done. That’s how it serves many users smoothly, and a big reason it’s fast. You mark the function async def and put await before the slow call:

The await says ‘this might take a moment — go do other work while we wait.’ For simple apps a normal def is fine; async earns its keep when you have lots of waiting and lots of users.

If the interview asks you

Tomorrow: a real database, so your data survives a restart.

Why these two papers feel impossible

Before a single formula, let us fix the real problem: it is not that Tax and Advanced Accounting are too hard. It is that you have been handed problems instead of methods.

You know the feeling. You solve a question, feel good, turn the page, and the next question looks completely new. You read the chapter again, do twenty more sums, and still every fresh problem feels like it is testing something you never saw. It is exhausting, and it quietly makes you believe you are just not built for these papers.

Here is the honest cause. Most study material hands you five hundred solved problems and quietly hopes the underlying method soaks in on its own. Some students absorb it by sheer volume. Most just drown, because they are trying to memorise five hundred separate answers instead of the handful of ideas hiding underneath them.

Because that feeling of endlessness is an illusion. And once you see through it, these two papers change from a bottomless pit into something you can actually finish.

The secret: the questions are finite

Behind the thousands of questions sits a small, countable set of solving methods. A method is a fixed way of attacking one type of problem. Tax and Advanced Accounting are not open-ended subjects where anything can be asked. Almost every question is one known method, wearing new numbers as a disguise.

How small? The whole of Advanced Accounting comes down to roughly nine methods. Income Tax is really one master sequence you follow every single time, with a few short routines and decision charts feeding into it. GST is a single pipeline of steps. Learn those, and you can face any question in the syllabus, including ones you have never seen, because there are no truly new questions, only familiar methods in new clothes.

So if a method is a master key, what exactly is inside one? Let us open it up.

What a method actually is

A method is just two things joined together. First, recognition: spotting which type of problem is in front of you. Second, a fixed sequence of steps that always solves that type. Recognise the type, run its steps in order, and the answer falls out. That is it.

The important part is that the steps do not change when the numbers change. An amalgamation problem is always the same march: decide the nature of the deal, compute the purchase consideration, close the seller's books, pass the buyer's entries, then draw the balance sheet. Different companies, different figures, same five steps, every time.

Now, why does this matter far more in a CA exam than in ordinary studying? Because of a quiet fact about how your paper is actually marked.

The grading secret: step marks

Your examiner does not only look at the final answer. Marks are given step by step: for the correct format, for each right working note, for following the proper sequence. This is called step marking, and it is the most reassuring fact in the whole course. Even if your final figure slips, every correct step along the way still earns its marks.

See what this does. Following the method is not only faster and calmer, it is literally what the marking scheme pays you for. A tidy, well-sequenced solution with clear working notes scores well even on a hard question, while a clever-looking jumble that skips steps often scores badly. The method and the marks are the same thing.

So how many methods are we really talking about? Let us lay the whole of each paper out on a single page, so you can see the finish line.

The whole map of Advanced Accounting

The entire paper fits into two families. On one side sit the Accounting Standards: a way to decide how a transaction is recognised and measured, plus a few standards that carry their own fixed formats like the cash flow statement, investment accounts, and consolidation. On the other side sit the company accounts chapters, each a set proforma.

That is the whole thing. Not an endless ocean, but two neat shelves. Every problem you will ever be set in this paper is one of these methods, asked with different figures. When you study a chapter, you are not collecting problems anymore. You are learning one more key for one more kind of lock.

Taxation looks bigger and heavier, but it is just as mappable. In fact its shape is even cleaner.

The whole map of Taxation

Income Tax is really one ladder you climb every single time. You work out income under each of the five heads, add them, make a few adjustments, and arrive at the tax. Each head, like salary or house property, is its own short routine, and a few decision charts tell you which rule applies. GST is one pipeline: a fixed chain of questions from is this a supply all the way to how much do I pay.

This is why toppers seem so calm in the exam hall. They are not solving each question from nothing. They glance at a question, recognise it as the salary rung, or the place-of-supply step, or the amalgamation method, and simply run the sequence they have run a hundred times before.

Every other book in this library teaches these methods one at a time, and each one is built the same way, as a Method Card. Knowing how to read a card is what makes the rest of the shelf click.

How to read a Method Card

Every method here is taught in the same six beats, always in the same order. Once you know the shape of a card, you know how to learn any method fast, because your eye always knows what is coming next.

First, when it fires: the tell-tale signs in a question that say this is the method you need, so recognition becomes automatic. Then the steps: the fixed sequence itself. Then why each step, so you understand it rather than memorise it. Then a worked example, the method run once on a real question, with the working notes that earn the step marks. Then traps and twists, the places students lose easy marks. Finally, drills, a few problems to run the method yourself until it feels like nothing.

One last thing before you start, and it is the difference between a card you read and a card that actually sticks: how to practise.

The mindset that makes it work

Three simple habits carry the whole method. First, when you feel stuck, do not panic and do not reread the chapter. Ask one question: which method is this? Naming the method is usually 80 percent of the battle. Second, drill by method, not at random. Do five problems of the same type back to back, until the steps feel automatic, before you move on. Third, always write every step out in full, because that is where the marks are.

As these habits settle in, something changes in how the exam feels. You stop dreading new questions, because you stop seeing them as new. A question you have never met before is just a familiar method in unfamiliar clothes, and your job shrinks to a calm first move: recognise it, then run the steps.

You now have the entire idea. Let us put it together in one breath, and then you are ready to open your first Method Card.

Bringing it all together

Here is the whole thing at once. Tax and Advanced Accounting feel infinite only because you were handed problems instead of methods. In truth the questions are finite: about nine methods for Advanced Accounting, one ladder plus a few routines for Income Tax, one pipeline for GST. A method is recognition plus a fixed sequence of steps, and the exam pays you step by step for following it. So you learn each method from its Method Card, you drill it until it is automatic, and you walk into the hall knowing there are no new questions, only familiar methods wearing new numbers.

That is the pattern method, start to finish. Not a trick and not a shortcut, just the honest structure that was always underneath these two papers. Every Method Card you open from here simply fills in one more key on your ring.

Doubts you might have right now

"Time is money." "She has a heart of stone." "The classroom was a zoo." Nobody thinks time is really cash or a heart is really rock. Yet everyone understands these at once. That instant understanding is a metaphor doing its quiet, powerful work.

A metaphor calls one thing another

A metaphor describes one thing by boldly saying it is another. Not that it is a bit like it, but that it simply is it: "the classroom was a zoo." You know the room was not full of actual animals. The word "zoo" hands over its feeling, noisy, wild, out of control, to the room.

That is the whole trick. A metaphor takes the qualities of one thing you already understand and lends them to another, so you feel the second thing through the first. It carries meaning across from the familiar to the new.

Its gentler cousin: the simile

A metaphor has a softer cousin called a simile. A simile makes the same kind of comparison but signals it out loud with the words "like" or "as": "he is brave as a lion," "her smile was like sunshine." It says "this resembles that."

A metaphor drops the "like" and the "as" and just declares it: "he is a lion." That makes it bolder and more vivid. The simile politely compares; the metaphor confidently states. Same bridge between two ideas, built with a little more or a little less caution.

Why it works so well

Metaphors are not just decoration for poets. They are one of the fastest ways humans understand anything hard. When an idea is new or abstract and has nothing you can picture, a metaphor lends it the shape of something you already know well.

That is why a good teacher reaches for one the moment a topic gets slippery. "Electricity flows like water in pipes." "An atom is a tiny solar system." The metaphor is a handle bolted onto an idea that had nothing to hold, so your mind can finally grip it.

You already think in metaphors

Here is the surprise. Metaphors are not rare, fancy things you meet only in poems. They are woven through ordinary speech so tightly that you use dozens a day without noticing a single one.

You grasp an idea, as if it were an object in your hand. You call someone a warm person, though their temperature is normal. Prices are high, time is running out, an argument gets heated. None of these are literally true, and all of them are instantly clear. Your everyday language is built on buried metaphors.

We do not just speak in metaphor, we think in it

Two thinkers, George Lakoff and Mark Johnson, argued something bigger: metaphor is not just a way of talking, it is a way of thinking. We understand whole abstract ideas by mapping them onto physical ones we have bodies for.

Look at how we talk about time: we save it, spend it, waste it, run out of it. That is the hidden idea "time is money" shaping every sentence. Or arguments: we attack a point, defend a claim, win or lose. That is "argument is war" running underneath. We reason about the abstract by borrowing the concrete, without ever deciding to.

Dead metaphors, and when metaphors mislead

Some metaphors get used so often they stop feeling like metaphors at all, and we call these dead metaphors. The leg of a table, the mouth of a river, the face of a clock, the foot of a mountain. Each once asked you to picture a body part; now the picture is gone and only the meaning remains.

A metaphor can also mislead, because it lends some traits but not all, and it is easy to carry across the wrong ones. If someone insists "the mind is a computer," the comparison lights up a few things and quietly hides others, memory in a machine is nothing like memory in a person. And piling clashing images together, a "mixed metaphor" like "that plan is a slippery slope with a lot of moving parts," just muddles the picture. A metaphor is a tool, and like any tool it can be used clumsily.

You may have noticed this book leans on metaphor constantly. Every "In real life" line, a fortress for the body, a night shift for sleep, a tug of war for floating, is a metaphor doing exactly what this chapter describes: handing a hard new idea the shape of something you already know. That is not a trick added on top of teaching. To a large degree, it is teaching.

If someone asks you

The whole idea

A metaphor describes one thing as another, lending the traits of something familiar to something new so you understand the second through the first. Its cousin the simile does the same but flags it with 'like' or 'as'. Far from being mere decoration, metaphor is one of the main ways we grasp hard and abstract ideas, and it is buried so deep in everyday language that we think in it without noticing. Learn to see metaphors, and you start to see the hidden scaffolding beneath almost everything anyone says.

Percentages are everywhere: 50% off, 90% charged, 20% tip, 8% interest. Most people push the buttons and hope. But there is one small idea underneath all of it, and once it clicks, percentages turn from scary to easy.

Percent just means 'out of 100'

The word percent comes from two Latin words meaning "per hundred", that is, "out of a hundred". So every time you see a percent sign, you can quietly read it as "out of 100" in your head.

So 50% is simply 50 out of 100. And 50 out of 100 is half. 25% is 25 out of 100, a quarter. 100% is 100 out of 100, the whole thing. The percent sign is just a shorthand for "out of one hundred".

Why always a hundred?

Here is the clever part. Fractions are hard to compare when their bottoms are different. Is 7 out of 10 better than 68 out of 80? You cannot tell at a glance, because one is out of 10 and the other out of 80.

So we agree on one common bottom number for everything: 100. Turn 7 out of 10 into 70 out of 100, and 68 out of 80 into 85 out of 100. Now it is obvious, 85 beats 70. Percent is just a shared yardstick that lets you compare any two amounts fairly.

Finding a percent of something

The most useful move is finding a percent of an amount, like 20% of 50 marks, or 15% of a bill. The rule follows straight from "out of 100": to find X% of a number, take X out of every 100 of it. In practice, divide the percent by 100, then multiply by the number.

So 20% of 50 is 20 divided by 100, which is 0.2, times 50, which is 10. That is it. Twenty percent of fifty is ten. The words "percent of" always mean "this many hundredths, multiplied by that".

Percent is everywhere

Once you see it as "out of 100", the whole world of percentages opens up. A 30% discount is 30 of every 100 rupees taken off. A battery at 90% has 90 of every 100 units of charge left. A 15% tip is 15 out of every 100 of the bill. Test scores, interest on savings, the chance of rain, they are all just parts out of a hundred.

Fractions, decimals, and percent are one family

A percent, a fraction, and a decimal are three outfits for the same idea. One half can be written as the fraction 1/2, the decimal 0.5, or the percent 50%. To go from a decimal to a percent, multiply by 100 (0.5 becomes 50%). To go the other way, divide by 100 (50% becomes 0.5). They are the same amount, just dressed differently for the occasion.

This is why the "divide by 100" step keeps appearing. A percent is secretly a fraction with 100 on the bottom, so 45% is really 45/100, which is 0.45. Whenever a calculation feels confusing, quietly turn the percent back into "out of 100" and it usually untangles itself.

The trap everyone falls into

Watch out for the difference between a percent and a percentage point. If a tax rises from 10% to 12%, that is a rise of 2 percentage points, but it is also a 20% increase (because 2 is one fifth of 10). News headlines mix these up constantly, and the two numbers tell very different stories.

And percentages can go above 100%. If something doubles, it grew by 100%; if it triples, by 200%. More than 100% simply means more than the whole you started with, which is perfectly fine, it just means you now have more than one of them.

If someone asks you

The whole idea

A percentage is nothing more than a count out of 100. That is the whole secret. We use 100 as a shared yardstick so any two amounts can be compared fairly. To find a percent of something, take that many hundredths of it. Fractions, decimals, and percentages are the same idea in different clothes. Read every percent sign as "out of 100" and the discounts, scores, and interest rates around you turn from a guessing game into simple arithmetic you can do in your head.

What is a share?

Before the charts and the news tickers, the whole stock market rests on one simple idea: owning a piece of a company.

A share is exactly what it sounds like: a small piece of a company that you can own. A big company is not owned by one person. It is cut into millions of equal little pieces, and each piece is one share. If you hold some of those pieces, you genuinely own that slice of the company, right alongside everyone else who holds shares.

Now the natural question is, why would a company let strangers own pieces of it at all? Because pieces can be sold, and selling pieces raises money. A company that wants to grow needs cash, and one clean way to get it is to sell small pieces of itself to many people. In return, those people become part-owners, called shareholders.

So where does this show up? In almost every large business you already know. The company behind your phone, your favourite snack, the bank that holds your salary, the app you order food on, most of them are owned by thousands of shareholders, not by a single boss. When a company's shares are open for the public to buy, we say it is listed.

But shares do not magically appear in people's hands. There is a first moment when a company decides to open itself up to the public, and that moment has a name. It is where our story really begins.

Why a company sells its shares

A company sells shares for one honest reason: it needs money, and this is a way to raise a large amount without only borrowing from banks. Building a new factory, hiring hundreds of people, or entering a new country all cost far more than day-to-day profit can cover. So the company offers pieces of itself to the public and, in exchange, receives a big pile of cash it can use to grow.

The very first time a company sells its shares to the general public has a special name: an IPO, short for Initial Public Offering. Before its IPO a company is private, owned by a few founders and early backers. On the day of the IPO it goes public, and from then on anyone, including you, can buy a share.

Why does a company agree to give away ownership for this? Because money raised this way does not have to be paid back like a loan, and there is no monthly interest. In return it simply accepts many new part-owners who now share in its future. It is a trade: a piece of ownership today, for the cash to become bigger tomorrow.

Once those shares are out in the world, owned by all sorts of people, a new question appears. If you did not buy at the IPO, how do you get a share later, and who exactly do you buy it from?

So what is the stock market?

The stock market is the place where people buy and sell shares that already exist. After a company's IPO its shares do not vanish; they pass from one owner to another, over and over. The stock market is simply the giant, organised marketplace where all of that buying and selling happens.

It is not a building you walk into. Today it is almost entirely electronic: a network of computers that matches people who want to buy with people who want to sell, in a fraction of a second. The organised places where this matching happens are called exchanges. In India the two big ones are the NSE and the BSE; in the United States you may have heard of the NYSE.

And how do you, sitting at home, reach this market? Through a broker: a licensed company, these days usually just an app, that is allowed to place your orders on the exchange for you. You do not deal with the exchange directly. You tap buy in the app, and the broker carries your request into the market. The market has fixed opening hours on working days, a little like a shop that is only open at certain times.

You will have noticed the price keeps changing, second by second, and nobody sits in an office deciding it. So the obvious question is: who, or what, actually decides the price of a share?

What makes the price move

A share price is not a fixed sticker value. It is simply the price at which a buyer and a seller last agreed to trade, right now. The company does not set it. It is decided, moment to moment, by the tug between how many people want to buy and how many want to sell. That tug has a name you will hear everywhere: supply and demand.

When more people want to buy a share than sell it, buyers compete and offer a little more, so the price rises. When more people want to sell than buy, sellers compete and accept a little less, so the price falls. That is the whole engine. Everything else, good news, bad news, rumours, results, works only by changing how many people feel like buying or selling at that moment.

So where do these swings of mood come from? Real things, mostly. A company announcing strong profits makes more people want to own it, so demand rises and the price climbs. A scandal, a weak result, or bad news for the whole economy makes people want out, so the price drops. A share price is really a live vote on how people feel about a company's future.

Understanding why the price moves is one thing. Actually owning a share is another. So let us walk through what really happens, step by step, the moment you decide to buy one.

Buying a share, step by step

Buying your first share feels mysterious, but it is a short, orderly journey. Before anything, you need two things, which most apps open together for you: a trading account, which places your orders, and a demat account, which holds your shares safely in electronic form, the way a bank account holds your money.

With the account ready, you add money to it, then search for the company you want. Now you place a buy order, and here you meet a small but important choice. A market order says buy now at whatever the current price is. A limit order says buy only if the price is at or below the amount I set. Beginners often start with market orders for well-known shares, and use limit orders when they want to control the exact price they pay.

The instant you confirm, your broker sends the order to the exchange, which looks for someone selling that share at a matching price and pairs you up in a flash. The trade is done. The share is moved into your demat account and the money leaves yours. The final tidying up, called settlement, usually finishes by the next working day, which is why you may hear the phrase T+1.

There is one quiet detail in that journey that trips up almost every beginner, and clearing it up removes a real fear. When you bought that share, who exactly did your money go to?

Who you really buy from

Here is the surprise: when you buy a share in the everyday market, your money does not go to the company. It goes to another investor, a person or a fund who owned that share and wanted to sell it. You simply took their place as the new owner. The company is not even part of that deal.

This is the difference between two markets that share one name. The primary market is the IPO itself, the one time the company sells new shares and gets the money directly. The secondary market is everything after: shares changing hands between investors, again and again, with the company standing aside. Almost every trade you will ever make is in the secondary market.

Why does this matter? Because it clears a common worry: if I buy shares, am I handing my savings to a company that might waste it? No. The company already got its money, once, at the IPO. After that, the share is just a thing of value passing between owners, and its price reflects what the next owner is willing to pay.

So if the company is not paying you, and you are simply holding a share, a fair question follows: what is actually in it for you? How does owning a share ever put money in your pocket?

The two ways you actually gain

Owning a share can reward you in two separate ways, and it helps to keep them apart in your head. The first is the one everyone knows: the price goes up. If you buy a share at one hundred rupees and later sell it at one hundred and thirty, that thirty-rupee rise is your reward. It is called a capital gain, and it only turns into real money the day you sell.

The second way is quieter and often missed. Many profitable companies share a slice of their profit with their owners each year, simply for holding the shares. That payment is called a dividend. You did nothing but own the share, and money lands in your account. Not every company pays one; younger, fast-growing companies often keep their profit to grow instead.

So where does this leave a patient owner? Often collecting both: a share that slowly rises in value and pays a small dividend along the way. That combination, quiet growth plus regular dividends, is what draws many people to shares over years rather than days.

You now understand a single share completely. But you will always hear people say the market went up today, or the market crashed. They cannot mean every share at once, so what exactly is this market that seems to have a single number?

Indexes, the market's scoreboard

When the news says the market rose one percent today, it is really talking about an index. An index is a carefully chosen basket of important companies, bundled into one single number that stands in for the whole market's mood. Instead of checking thousands of shares, you glance at one figure and get the gist.

In India the two famous ones are the Sensex, built from 30 large companies on the BSE, and the Nifty 50, built from 50 large companies on the NSE. In the United States the best known is the S&P 500, which follows 500 big companies. When most of the companies in the basket rise, the index rises, and we say the market was up.

Why does this exist? Because how is the market doing is too big a question to answer share by share. An index answers it in one glance, and lets people compare today with last year, or one country with another. It is the single score that sums up a very long, complicated game.

By now the stock market might sound like a tidy machine that only climbs and hands out free money. It is time to be honest, because that picture is exactly how beginners get hurt.

Risk, and the myths that hurt beginners

Here is the plain truth: share prices fall as well as rise, sometimes sharply, and no one can promise you a profit. The same supply and demand that lifts a price can crush it when people rush for the exit. Any money you put into shares can shrink, and it is completely normal for a new investor's first big red day to feel awful. Everyone who invests has lived through it.

So how do sensible people handle the risk? First, they diversify, a long word for a simple habit: do not put all your money into one company. Spread it, so one bad surprise cannot wipe you out. Second, they think in years, not days, because good companies tend to grow over long stretches even while they wobble constantly in the short term. Third, they only invest money they will not need soon.

You have now seen every moving part: the share, the company, the market, the price, the buying, the two gains, the scoreboard, and the risk. Let us put the whole loop together in one breath.

Bringing it all together

Here is the entire idea in one flow. A company cuts itself into shares and sells them to the public in an IPO to raise money. After that, those shares trade between investors on the stock market, reached through a broker app, where the price rises and falls purely on supply and demand. You can gain if the price climbs, or if the company pays a dividend, or both. Indexes like the Nifty and the Sensex sum up the whole market in one number. And through all of it, prices can fall, so you spread your money and you think in years.

That is the stock market, start to finish. Not a casino, not magic, just a marketplace for owning small pieces of real businesses. Everything more advanced you ever read will simply hang on this one simple frame.

If the interview or quiz asks you

Look up on a clear day and the whole sky is blue, edge to edge. The sun is not blue. Space is not blue. So where does all that blue come from? The answer is hiding in the air itself.

Sunlight is really every colour at once

The light from the sun looks plain white, or pale yellow. But that white is a kind of trick. It is really every colour mixed together at once, red, orange, yellow, green, blue and more, all travelling to you inside one beam.

You have seen them split apart before. A rainbow is nothing but sunlight broken open into the real colours that were always inside it. So is the little band of colour that spills onto the floor from a glass of water on a sunny sill.

The air is full of tiny bumpers

The air looks empty, but it is not. It is packed with unbelievably tiny specks of gas, mostly nitrogen and oxygen. They are far too small to see, much smaller even than a fleck of dust.

As sunlight pours down through the air, it keeps bumping into these tiny specks. Each bump can knock a little of the light off in a new direction. This bouncing-off has a name: scattering.

Small colours get bounced the most

Here is the heart of it. Each colour of light is really a wave, and some waves are shorter than others. Blue and violet are short, tight waves. Red and orange are long, lazy waves.

When light meets those tiny specks of air, the short waves get knocked about far more than the long ones. Blue light scatters strongly and flies off in every direction. Red light mostly ignores the specks and carries straight on.

This bouncing of light off specks far smaller than the light itself has a proper name: Rayleigh scattering. Its rule is surprisingly steep. Halving a wave's length does not scatter it just a little more, it scatters it about sixteen times more, because the strength grows with the wavelength to the fourth power. That sharp rule is why the short blue waves get thrown around so overwhelmingly more than the long red ones, and why the effect is strong enough to paint a whole sky.

So the whole sky lights up blue

All that scattered blue light does not just vanish. It bounces from speck to speck and comes down to your eyes from every part of the sky at once.

That is why the blue seems to come from nowhere and everywhere. You are not looking at a blue sun. You are looking at blue light that has been bounced around the air above you until it reaches you from all sides.

This also explains why the sky is a deep blue overhead but pale, almost white, down near the horizon. When you look straight up, the light reaches you through only a thin slice of air. When you look toward the horizon, that same light has crossed far more atmosphere, and the blue has been scattered and re-scattered so many times that it washes out into a pale, milky band where the sky meets the ground.

Then why are clouds white?

If air scatters blue, you might expect clouds, which are also in the sky, to look blue too. They do not, and the reason is a lovely twist on the same idea. Clouds are not made of gas specks. They are made of tiny water droplets, and a droplet is huge compared to an air molecule, far bigger than the waves of light.

When light meets something that big, it no longer favours the short blue waves. Instead every colour is scattered more or less equally, a different regime called Mie scattering. All the colours bouncing off together add back up to white, which is why clouds look white, and why a thick storm cloud, which lets little light through at all, looks grey.

Then why isn't the sky violet?

Good catch. Violet waves are even shorter than blue, so by the rule so far they should scatter even more, and the sky should be purple. But it is not, and there are a few honest reasons stacked together.

The sun sends out less violet light than blue to begin with. On top of that, a little of the violet is soaked up high in the air. And most of all, your eyes are simply far more sensitive to blue than to violet.

So the air really is scattering a mix that leans violet and blue. But by the time your eyes add it all up, the answer they hand you is a clean, calm blue.

Why sunsets turn red and orange

The same one rule explains the other lovely thing the sky does. At sunset the sun sits low, near the horizon, so its light has to travel through far more air to reach you than it does at midday.

Over that long journey almost all the blue is scattered away long before it arrives. What survives the trip is the light that never bounced much in the first place, the reds and oranges. So the low sun glows warm.

Why space has a black sky

Here is a neat check on the whole idea. Astronauts in orbit see the sun blazing, yet the sky all around it is pitch black. Why? Because up there is no air.

No air means no tiny specks to bounce the light around. With nothing to scatter it, no blue is spread across the sky, so it stays black even in full sunlight. The blue sky is a gift of our atmosphere.

If someone asks you

The whole idea

White sunlight is every colour at once. The air is full of tiny specks. Those specks knock the short blue waves all over the sky, so you see blue from every direction. When the sun sits low, the blue is scattered away and you get a red sunset. And with no air at all, there is no blue, just black. Every clear blue day is the air quietly sorting the sun's colours for you.

A huge steel ship floats. A tiny steel nail sinks. Both are made of the same heavy metal, so weight alone cannot be the answer. Something more interesting is going on, and once you see it, floating will never look like magic again.

Floating is a tug of war

Whenever something sits in water, two forces are fighting over it. Gravity pulls it down, the way it pulls everything down. That downward pull is just the object's weight.

But water pushes too. It pushes up on anything placed in it, with a force we call upthrust or buoyancy. If the upward push is as strong as the weight pulling down, the object floats. If the weight wins, it sinks.

Where the push comes from

So why does water push up at all? Because when you put an object in, it has to shove some water out of the way to make room. The water does not like being shoved, and it pushes right back.

Here is the exact rule, and it is a beautiful one: the upward push equals the weight of the water the object shoves aside. Push aside a lot of water, and you get a strong upward push. Push aside only a little, and the push is weak.

This idea is over two thousand years old. The Greek thinker Archimedes is said to have discovered it in his bath: as he sank in, the water rose, and he realised the amount that overflowed matched the space his body took up. The rule still carries his name, Archimedes' principle.

The real rule: density

Now we can answer the puzzle. An object floats if it is lighter than the water it pushes aside. If a block shoves aside a bucket of water but weighs less than that bucket, the water wins the tug of war and holds it up.

There is a neat word for how heavy something is for its size: density. Cork is light for its size, so it is less dense than water, and it floats. Stone is heavy for its size, denser than water, so it sinks. Float or sink is really a contest of densities.

Density has a simple meaning: how much stuff is packed into a space. Squeeze a lot of weight into a small volume and you get something dense, like a stone. Spread a little weight over a big volume and you get something light for its size, like cork or a balloon. Anything less dense than water floats on it; anything denser sinks.

So how do steel ships float?

Back to the puzzle we started with. A solid lump of steel sinks instantly, because steel is far denser than water. Yet a giant steel ship, far heavier, floats calmly. The secret is not the steel. It is the shape.

A ship is shaped like a huge hollow bowl, mostly full of air. That shape pushes aside an enormous amount of water, far more than a solid lump would. And because it is mostly air inside, the whole ship, air and all, is lighter than the water it shoves aside. So it floats.

This is why a submarine can choose to float or sink. It has tanks it can fill with water to become heavier and dive, then blow the water out with air to become lighter and rise. It is changing its own density on purpose, tipping the same tug of war whichever way it wants.

If someone asks you

The whole idea

Floating is a tug of war between an object's weight pulling down and the water's push lifting up. That push equals the weight of the water the object shoves aside. So anything lighter than the water it displaces, anything less dense, floats, and anything denser sinks. Change the shape, like a lump of steel into a ship, and you change how much water it shoves aside, which is why the heaviest ships float while a small nail drops straight to the bottom.

You spend about a third of your whole life asleep. That is a strange amount of time to give up if sleep were just doing nothing. It turns out sleep is one of the busiest, most important things your brain and body ever do.

Sleep is not the body switched off

It is easy to think of sleep as the body powering down for the night, like a phone going dark. But that is not what happens. When you sleep, your brain stays remarkably active, and it gets to work on jobs it simply cannot do while you are awake and busy.

Sleep is more like a night shift. While you rest, a whole crew comes on duty inside you: filing away what you learned, cleaning up mess, and repairing the day's wear. You wake up feeling new because, quietly, you were rebuilt.

It files away your day

All day you take in a flood of new things: names, facts, a route, a skill. During the day these memories are fragile, held loosely. One of sleep's biggest jobs is to take the important ones and move them into long-term storage, so they last.

This is why sleeping after you study beats staying up all night cramming. The all-nighter feels productive, but without sleep the brain never gets to file what you learned, so much of it slips away by morning.

It washes the brain clean

Your brain is busy all day, and like any busy machine it builds up waste, leftover by-products of all that thinking. This waste needs to be cleared out, and here is the surprising part: the clean-up happens mainly while you sleep.

During deep sleep, tiny spaces in the brain open wider and fluid flushes through, rinsing the waste away, a bit like a nightly wash cycle. Scientists call this the glymphatic system. It runs best in deep sleep, which is one reason a truly restful night leaves your head feeling clear.

It repairs and restocks the body

Sleep is not only for the brain. While you rest, your body repairs muscle, mends small daily damage, and does much of its growing, which is why children and teenagers need so much of it. Your immune system, the germ-fighting crew, also restocks overnight.

That is part of why rest helps so much when you are unwell, and why a bad night can leave you feeling run down. The repair crew simply did not get enough time on the job.

One night is a set of loops

A night of sleep is not one flat state. You cycle through stages again and again, roughly every ninety minutes: light sleep, then deep sleep, then a dreaming stage called REM, and around again. Each loop does different work.

Deep sleep is when much of the filing and the brain-washing happen. REM, the dreaming stage, helps sort out emotions and lock in skills. A full night lets you complete several loops, which is why cutting sleep short, and losing those last loops, leaves so much undone.

Which loop does which job

The two heavy-lifting stages divide the work. Deep, slow-wave sleep is strongest early in the night, and it is where facts and information get consolidated into long-term memory, and where the brain's wash cycle runs hardest. REM sleep grows longer toward morning, and it is more about emotions, and about locking in skills and movements, the things you learn by doing.

This is also why the timing of a short sleep matters. Cut a night off early and you lose mostly the later REM-rich loops, which can leave emotions frayed even if you got your deep sleep. The stages are a sequence, and skipping the end skips real work.

Waste, dreams, and the long game

The brain's nightly wash is more than tidiness. Among the things it clears are sticky proteins that build up with thinking; over many years, poor clearance is one of the threads scientists are studying in brain-ageing conditions like Alzheimer's. This is an active area of research, not a settled story, but it is a big reason sleep is taken so seriously now.

And dreams? We still do not fully know why we dream, which is a wonderful thing to be able to say honestly. The leading ideas connect REM dreaming to sorting through emotions and weaving new memories into old ones, a kind of overnight rehearsal. Some of the biggest questions in this field are still open.

How much sleep a person needs changes with age: young children need the most, teenagers still need more than they usually get, and most adults settle around seven to nine hours. These are general guides, not rules, and everyone is a little different.

If someone asks you

The whole idea

Sleep is not the body switched off, it is the body's night shift. In deep sleep your brain files the day's learning into lasting memory and flushes out its waste; in REM you sort emotions and lock in skills; all night your body repairs and your defences restock. You loop through these stages several times, so a full night matters. You give up a third of your life to sleep not because it is wasted time, but because it is when you are quietly rebuilt for the day ahead.