Most ISRO CS candidates revise the same syllabus twice and still practise only one response mode. The written test rewards a decision inside 90 seconds: recall the power of two, calculate, eliminate the distractor, move on. The interview rewards the opposite reflex, saying the assumption out loud and holding it through four follow-ups. One paging question does both jobs, as a 4 MiB single-level answer on paper and a 132 KiB two-level defence in front of a panel.
ISRO CS written test and interview are two response modes
Advertisement ICRB:02(EMC):2025 runs the CS route in that order: a written test, written-test results, a shortlist for interview, then an interview schedule. Each recruitment publishes its own advertisement, so read yours for the stage list that applies to you.
Four demands separate the two stages, and each one needs its own rehearsal.
Demand | Written-test practice response | Interview-practice response |
|---|---|---|
Breadth | Choose across mixed CS topics | Connect one topic to adjacent concepts |
Time pressure | Decide and move | Think aloud without rambling |
Evidence | Calculate or eliminate options | State assumptions, trade-offs and examples |
Project | Usually absent from a technical MCQ drill | Explain personal contribution and measured result |
The ISRO Scientist/Engineer CS preparation category collects the Scientist/Engineer 'SC' Computer Science route, so you can see which subjects a course actually drills before you block out your weeks.
Written-test preparation: breadth, recall and a fast calculation loop
The live course drills six subject blocks: Data Structures and Algorithms, Operating Systems, DBMS, Computer Networks, Software Engineering and basic Artificial Intelligence, alongside technical MCQ sets, aptitude, PYQs and full mocks. Breadth is what the written stage actually tests, so touch all six every week instead of finishing one subject before starting the next.
Paging drill: 32-bit virtual addresses, 4 KiB pages, 4-byte page-table entries.
4 KiB = 2^12 bytes, so the page offset is 12 bits.Virtual pages =
2^(32-12) = 2^20.Table size =
2^20 x 4 bytes = 2^22 bytes = 4 MiB.
Give yourself 90 seconds on a question like this, 60 to calculate and 30 to check that you read the page size in bytes. Write the powers down, calculate, then reject the two standard distractors: an entry sized in bits instead of bytes, and any option computed from physical memory rather than the 32-bit virtual address space. Mark the question K (know), E (eliminated) or G (guessed), then move on. Working through the PYQ practice method shows you which of those two mistakes you keep repeating.
Interview preparation: make the same concept survive follow-ups
Allow 8 minutes here, because a panel will not accept the number on its own. Open by naming the model: one flat page table, 32-bit addresses, 4 KiB pages, and the 4 MiB result that follows. Then show what changes when a process maps only 128 MiB, which is 128 MiB / 4 KiB = 32,768 pages. At 1,024 entries per 4 KiB table page that needs 32 table pages, so 32 x 4 KiB = 128 KiB, and one 4 KiB directory on top makes 132 KiB. Say which two-level layout you assumed, because a real x86-64 machine walks four levels rather than two and would give you a different figure.
Sparse allocation builds tables only for the ranges a process actually uses, which is where the saving comes from. A TLB caches virtual-to-physical translations, so a TLB miss costs another lookup, while a page fault needs the operating system to step in because the access cannot complete. Defend your assumptions, correct your own overstatements, and connect the memory model to performance. The technical interview CS subjects guide gives the same treatment to OS, DBMS, CN and OOP, so you can build one out-loud answer per subject.
Project ownership: prepare evidence, not a memorised summary
Work this example, then substitute figures your own repository, logs or tests can prove. An API served 1,000 requests per minute at 420 ms p95 latency, with 900 database reads per minute behind it. You added Redis with a 60-second TTL, p95 fell to 240 ms and reads dropped to 280 per minute, so roughly 69 percent of reads stopped reaching the database.
Cover five parts: the problem and its baseline, your exact contribution, how you measured, the cost of data being stale for up to 60 seconds, and what happens on failure, which is bypassing Redis and reading the database. Expect four follow-ups: why 60 seconds and not 10 or 300, how p95 was measured, what prevents a cache stampede, and what would trigger a rollback. If you wrote only the API route and a teammate configured Redis, say exactly that. Never claim the whole system and never invent a metric.
Convert one written error log into interview depth
After every written practice set, take the questions you marked E or G and put them in a five-column log. The last two columns are what turn a wrong answer into an interview answer.
Written miss | Correct answer | Why my shortcut failed | Two-minute explanation | Likely follow-up |
|---|---|---|---|---|
512 KiB | 4 MiB | Multiplied | Derive | Compare it with the 132 KiB sparse model |
32,768 page tables | 32 page tables | Counted mapped pages instead of table pages | 1,024 entries fit in one 4 KiB table page | What if the process maps 1 GiB? |
Seven-day bridge:
Days 1 to 4: 40 mixed questions daily; log wrong or guessed items.
Day 5: make 10 logged items into two-minute oral explanations.
Day 6: two 20-minute technical mocks.
Day 7: a 10-minute cache-project defence, recorded once and replayed.
Miss a day? Cap the next day at 50 and push the rest forward, rather than attempting an 80-question catch-up that only manufactures guesses. There are more than 55,000 questions in the practice bank to draw those 40 a day from, and the ISRO Scientist/Engineer SC (CS) course groups its technical MCQ, PYQ, mock and interview-guidance sets so you are not choosing at random.
Five preparation mistakes that make one stage weaken the other
Why it happens | What goes wrong | What to do instead |
|---|---|---|
Definitions without timed use | Written decisions stay slow | Use the 90-second paging drill |
MCQ-only practice | Oral answers become brittle | Add the 8-minute follow-up drill |
Unstated assumptions | Confident answers become invalid | Name the architecture model first |
A polished project monologue | Follow-up evidence is weak | Use the 1,000/420/900 baseline and 240/280 result structure |
Treating a course description as the exam pattern | Your stage list goes stale between recruitments | Read the current advertisement on ISRO Careers |
Never invent an answer. Say: “Under this assumption, I would calculate it this way; I would verify the architecture-specific detail,” then commit to that result. Do not hedge every answer.
Final rehearsal: two checkpoints, one official-source check
Run one full rehearsal. Thirty minutes for 20 mixed written questions, then five minutes marking each one K, E or G. Then thirty interview minutes: 8 on paging, 10 on the cache project and 12 on follow-ups. Close with two questions. Where did time or accuracy leak, and which assumption, trade-off or metric could you not defend?
The short version: make timed, checked decisions on paper, turn every miss into a two-minute spoken explanation, and walk in with one project whose numbers you can prove. Then confirm the route, format, shortlisting rule and interview schedule for your own cycle on the official ISRO Careers page, since every advertisement sets its own.
