You can describe your project from the resume, but then the questions change: Why this database?, What fails when two requests arrive together?, or Draw it. All three are answerable from one project, provided you have turned it into evidence, trade-offs and a diagram you can draw while speaking. ISRO's own centre pages say where most of its computing work sits: ISTRAC in Bengaluru runs mission operations and provides telemetry, tracking and command support for every satellite and launch-vehicle mission, and NRSC in Hyderabad acquires, processes and disseminates remote-sensing data. Software of that shape is judged on not losing a record, recovering after a link outage, and behaving the same way on every run, so pick the project you can defend in those terms rather than the one with the biggest user count.
Check the official interview context before practising
Start at the official ISRO Careers page, open Current Opportunities, and find the exact notice linked to your application or call letter. Copy a three-line fact sheet from that notice: post/discipline, selection stage named in the notice, and documents or instructions for that stage.
Do not carry an older recruitment's marks, ratio, schedule, venue or document list into this cycle. If the notice does not state a panel format, question count or duration, record that. The ISRO Scientist/Engineer CS preparation catalogue lists the subject courses. If you are still unclear on how the written test and the interview reward different things, read ISRO CS Written Test vs Interview first.
Turn one real project into a 90-second evidence map
Take one worked example: LabSlot, a laboratory-slot booking API for 3,000 registered students, 12 labs and 20 bookable slots per lab per day. That gives 12 x 20 = 240 bookable slots a day. Substitute your own figures, and only figures your repository, logs or tests can prove.
Build the answer in five blocks:
Problem: prevent two users taking the same lab and start time.
Contribution: “I wrote the PostgreSQL schema and transaction path; my teammate built the web interface.”
Design: accept
user_id,lab_idandslot_start.Evidence: enforce
UNIQUE(lab_id, slot_start)and test one empty slot with60simultaneous attempts.Limitation: one database deployment, tested only at that load.
Spoken end to end, that map runs about 90 seconds: roughly 15 seconds each on the problem and your contribution, 20 on the design, 25 on the evidence, and 15 on the limitation. Never present team work as personal work.
Draw the architecture, then defend each choice
Draw left to right: actor, request, decision, data store, response. For LabSlot: student web client -> POST /bookings -> authentication and validation -> PostgreSQL bookings table -> HTTP response. Above the database, write the invariant: at most one row for each (lab_id, slot_start).
PostgreSQL fits because the records are related, the uniqueness rule belongs at the source of truth, and a transaction keeps the decision atomic. Another database could also work. Defend the fit, not the brand.
A successful insert returns 201 Created; a duplicate returns 409 Conflict. Beyond 60 concurrent attempts, separate measured evidence from the next proposed test.
Number each step while speaking so a follow-up does not break the diagram. Clearly label request fields, the invariant and both response codes instead of hiding behaviour inside unnamed boxes.
Whiteboard the race condition one event at a time
Name the invariant first: one slot can have at most one booking. Now show the unsafe interleaving. At t0, A runs SELECT and sees zero bookings. At t1, B also sees zero. At t2, A inserts. At t3, B inserts. Without a database constraint, the application check permits two rows for one slot.
With UNIQUE(lab_id, slot_start), A commits and receives 201. B attempts the same insert, the database rejects the duplicate key, and the API maps it to 409. One round of 60 simultaneous requests for one empty slot must end in exactly 1 creation and 59 conflicts, because 1 + 59 = 60.
Speak in this order: invariant, bad interleaving, enforcement point, client result, limitation. Use the OS interview questions for freshers to drill race conditions and critical sections until you can lay out the interleaving in order without notes.
Handle changed assumptions without bluffing
Prepare three follow-ups. If PostgreSQL is unavailable for 5 seconds, do not report success. Return a retryable 503 and preserve an idempotency key such as u27-lab3-20260720T1000. If traffic may rise from the tested 60 simultaneous attempts to 300 requests/second, call it unverified and propose 10-minute stages at 100, 200 and 300 requests/second. If a user retries after a timeout, use the key to prevent a second logical booking.
An honest limitation, rather than guessing: “I did not test database failover. Next, I would terminate the primary during a 10-minute test, record rejected and retried writes, and verify that the unique-slot invariant still holds.”
If your project looks more like a ground-segment job than a web API, rehearse the same three moves on its own terms: a fixed-rate input stream that arrives only inside a limited ground-station pass window, a link that drops with one record half written, and a restart that must not store the same reading twice. The order of the answer does not change, which is the invariant first, the enforcement point second, and the measured limit last.
Connect project choices to CS fundamentals
Project decision | CS concept | Likely follow-up |
|---|---|---|
Composite unique key | DBMS constraints and indexing | What is the index cost? |
Concurrent insert | OS critical-section reasoning | Where is atomicity enforced? |
| HTTP semantics | Which failures are safe to retry? |
Student, lab, booking entities | Data modelling | Why these keys and cardinalities? |
For an algorithm pivot, take half-open intervals [09:00,10:00), [10:30,11:15) and [13:00,14:00). Proposed [09:45,10:45) overlaps the first because 09:45 < 10:00, and the second because 10:30 < 10:45. Sort by start time in O(n log n), then scan adjacent intervals in O(n). The DSA interview guide has more whiteboard drills.
KnowledgeGate carries more than 50,000 practice questions across subjects. Work 5 DBMS + 5 OS + 5 network questions a week out loud, saying why each answer holds.
Use a seven-day rehearsal loop
Use a 45-minute loop: Day 1, evidence sheet; Day 2, redraw twice; Day 3, narrate the race; Day 4, failure prompts; Day 5, fundamentals and intervals; Day 6, record a mock; Day 7, repeat the weakest answer. Score accuracy, structure, evidence, trade-off and legibility from 0 to 2, total 10. A 6/10 or below means you repeat that same answer the next day instead of starting a new project.
The short version: prove what you built, state the invariant before the technology, use evidence, expose a limitation, and draw while speaking. Then work the syllabus itself in the ISRO Scientist/Engineer SC (CS) course, and recheck the official notice before you rely on any recruitment detail.
