They ask: "Explain Go's GMP scheduler model — what are G, M, and P?"
Go multiplexes many goroutines onto a small number of OS threads, and GMP is the bookkeeping that makes that work. G (goroutine) is a lightweight unit of work with its own small growable stack. M (machine) is an OS thread — the thing the kernel actually schedules. P (processor) is a logical context that holds a local run queue of runnable Gs and the resources (like a memory cache) an M needs to execute Go code; an M must hold a P to run Go code at all. The number of Ps is capped by GOMAXPROCS, which is why that setting — not the number of goroutines — controls actual parallelism.
Say it: "GMP decouples goroutines from OS threads: P is the scheduling context that bounds parallelism to GOMAXPROCS, M is the OS thread doing the work, and G is the lightweight goroutine — that indirection is what lets Go run millions of goroutines on a handful of threads."
Red flag: Saying "a goroutine is a thread" flatly — it's scheduled cooperatively by the Go runtime onto a small thread pool, which is exactly why they're 100x-plus cheaper to spawn.