Interview prompt
Explain when a runtime compiles hot code to an engineer who understands the surrounding system but has not used this technique. Walk from its contract to a concrete operation, then discuss where it fails or becomes expensive.
A strong answer
A just-in-time compiler translates code while a program runs. A runtime may begin by interpreting or compiling quickly, then use execution counters or profiling to identify frequently executed paths worth optimizing. The result can be specialized using assumptions about observed types and control flow.
If a function repeatedly receives integers, a JIT may generate a fast integer path guarded by a type check. If later calls use another type, the guard can fail and execution falls back or deoptimizes to a less specialized representation. This lets the runtime trade compilation cost for faster repeated work.
A complete answer also calls out the assumptions that control correctness. Warm-up behavior means short benchmarks can measure a different execution mode from long-lived production. Aggressive optimization can increase code size and compilation latency. A deoptimization is not necessarily a bug; it is a correctness-preserving response when an optimization assumption no longer holds.
Close by describing one representative test or measurement. Design a benchmark to compare an interpreter and a JIT fairly. Explain why including startup and warm-up in one run can answer a different question than steady-state throughput.
Follow-up questions
Answer the follow-ups in the frontmatter. Use the linked article for the concept and the trace to make the explanation concrete.