ET-3 — Final revision session (3 Sept 2026)¶

~12 min read · no paper this time — the professor talked about the exam itself · the 50% subjective split · reasoning over syntax

The last revision session before the ET, and the most important one: no paper walkthrough this time. The professor explained what the end-term will actually look like this term — and it's a bigger change than the earlier sessions suggested.

The exam this term — what he said¶

The format, straight from the professor

About half the paper is subjective questions. The other half stays objective (MCQ/MSQ-style). Roughly 20 marks each on the 40-mark paper.
The question structure will be new. He said the formats test structural thinking in ways "probably something you have never seen in the diploma level so far." Concepts you know, asked in new shapes.
One confirmed question format: you get a software problem (say, a buggy script) and must write the prompt you'd give a coding agent (like Codex) to solve it. Your prompt-writing is the answer.
No live evaluation. Unlike GAs, there's no green-tick loop — submissions are collected first (like an ROE) and evaluated afterward. Check your own logic before submitting.
Syntax is not the metric. "We are least concerned about syntax." No writing exact YAML, no exact Dockerfile strings. What's graded: approach, reasoning, critical thinking.
No pen-and-paper calculations — it's a reasoning exam.

How to read this: the professor kept repeating one theme — the "why" behind the "how." Commands and syntax are tools; the exam measures whether you can justify and design. That's good news: it rewards understanding the concepts this site already teaches, and it makes rote memorization worthless.

PYQs — how to use them

Asked whether PYQs still help (the syllabus has changed), he said: use them to predict the core concepts, not the exact questions. And don't take a deep dive into very old papers — the most recent three papers are enough. We hold exactly those four sessions' worth; see the solved papers.

Relative grading — how the final grade works¶

The professor explained the mechanics of the bell curve:

Marks are normalized across the cohort — your grade depends on how you perform relative to everyone else, not just your raw score.
Statistically, about half the cohort falls below the median, whatever the paper's difficulty.
Projects are the exception: the team plans to make the project grader public (criteria and test cases visible) — project grading stays absolute, not relative.

What this means for you: on a hard paper, everyone's score drops — the curve restores the balance. Don't panic if the paper feels tough; it feels tough for everyone, and only your relative position matters.

Bonus marks — 99% not happening

A student asked if bonus marks are final. The team found no major unresolvable issues in the assessments, so: "99% we won't be having bonus." For GA5's buggy final question, the fix was a deadline extension + a more permissive grader, not flat compensation. Plan your score calculations without bonus.

Case study: the sentiment API (his example of a subjective question)¶

This is the sample subjective scenario he walked through — a student's FastAPI sentiment analysis endpoint from a previous term:

The symptoms:

Invalid inputs cause silent downstream failures — no clear errors
An empty text parameter still returns "positive" — the service "works" while doing nothing

The real flaw he pointed at: the endpoint function stores a hardcoded placeholder in a variable and returns it directly. It never reads the request body, never runs any model. He called this "functionally dead" — and the point of the question is not to hunt for syntax typos, but to identify this semantic flaw.

What a strong answer fixes (under 200 words):

Real inference — replace the hardcoded return with an actual model call
Input validation — Pydantic schema + type hints at the boundary; reject empty strings with a clear 400
Exception handling — catch malformed JSON and inference timeouts instead of failing silently

GET vs POST — the follow-up he guaranteed¶

For an ML inference endpoint, GET is a design flaw:

	GET	POST
Where the text goes	URL query params	request body
Who sees it	browser history, proxy logs, network trails	nobody in transit logs
Long documents	fails — strict URL length limits	fine
Auth headers	awkward	clean, standard

The one-line answer to remember: POST encapsulates the payload safely in the body, has no length limit, and carries authentication headers — GET exposes input in logs and breaks on long text.

Shell config — `source` and the current session¶

Environment variables live in ~/.bashrc (the config file your shell reads at startup). Add one:

export API_KEY="dev_99x"   # appended to ~/.bashrc

The trap: a new line in .bashrc does nothing to your already-open terminal. The file is only read at shell startup.

The fix — run the file inside your current session:

source ~/.bashrc   # or the shorthand:  . ~/.bashrc

source executes every line of the file in your live shell, so new variables, aliases, and functions register immediately — no restart.

`grep -r` — don't forget the dot¶

The correct command to search recursively for "input" from where you stand:

grep -r "input" .

-r — recursive: search every file, then dive into every subdirectory
. — the search origin: the current directory

The trap he named: omit the dot and grep waits on stdin — the terminal looks hung, but it's actually waiting for you to pipe data in. Nothing is broken; nothing was searched.

Shebang — when `#!` matters and when it doesn't¶

The shebang (#!/bin/bash) is a kernel directive read only when you run a script directly as an executable (./script.sh). The OS reads the interpreter path, launches it, and pipes your file into it.

The override rule (his doubt-session answer): if you invoke the interpreter explicitly — python3 script.sh — the shebang is completely ignored. The command line wins. That's why a .sh file with a bash shebang can still execute under python3 (and produce bash syntax errors).

Do you need to write shebangs in the exam? No absolute requirement — shebangs only enable self-executability.

The `os` module — Python's bridge to the system¶

Function	Purpose
`os.environ` / `os.environ.get("KEY")`	read (and write) environment variables — `.get()` returns `None` instead of raising `KeyError`
`os.chmod()`	change file permissions
`os.cpu_count()`	logical CPUs — not physical chips
`os.chroot()`	change the active root directory

The distinction he drilled: os.cpu_count() counts logical threads (with hyper-threading, typically 2× the physical cores) — not silicon chips.

Reading an API key safely:

import os
api_key = os.environ.get("Apk")   # None if missing, no crash

His study tip: learn any module from the terminal — import os, then help(os) — the built-in docs, no browser needed.

VS Code — Command Palette vs file search¶

Shortcut	What it does
Ctrl+Shift+P (Cmd+Shift+P on Mac)	Command Palette — runs actions (e.g. "Reload Window")
Ctrl+P	quick-open — searches file names

The Palette is one searchable bar for everything the editor can do — a pattern borrowed from Emacs. Press Ctrl+P and delete the > to switch from commands to filenames.

The traps from this session¶

🔴 GET for ML inference — exposes input in logs, breaks on long text. The answer is always POST.
🔴 Single quotes in JSON — json.loads("{'score': 10}") fails: standard JSON requires double quotes.
🔴 .bashrc without sourcing — changes don't apply to the open terminal. source it.
🔴 grep -r without the dot — looks hung, actually waiting on stdin.
🔴 os.cpu_count() = physical chips — no: logical threads.
🔴 "Write this in Python" as a whole prompt — too vague; a good agent prompt carries role, context, task, and constraints.

What this session changes about your prep¶

Half your marks come from writing. The LLM-grading guide is now the highest-value page on this site — read it, then practice with the mocks and the short-answer bank.
Study concepts, not answers. PYQs tell you which concepts get asked — the question shapes will be new. Our topic pages and short notes exist exactly for this.
Practice writing agent prompts. It's a confirmed question format: given a problem, write the prompt for Codex — with role, context, task, and constraints. The LLM & prompting notes cover the structure.
Recent papers only. The last three papers are enough — exactly the ones solved on this site.