You own a stage of a pipeline that turns text into machine code, inside a codebase of millions of lines that thousands of people depend on being correct. Most days are not writing new optimizations. They are reducing a bug report to twelve lines, bisecting which pass broke it, reading IR before and after, writing the FileCheck test that would have caught it, and defending the patch in review.

• Triage a report: reproduce, reduce with llvm-reduce or creduce, bisect the pass with -opt-bisect-limit
• Read IR at three stages and say which transformation was wrong
• Write or fix a pass; keep the analyses it preserves honest

Someone hands you a program that is too slow and no idea why. Your value is that you do not guess. You build a repeatable measurement, find the bottleneck with evidence, name the mechanism, change one thing, and prove the change with numbers a sceptic would accept. Half the job is refusing to accept a plausible story without a counter behind it.

• Turn a vague complaint into a repeatable workload with a known noise floor
• Profile it, get from wall time to a source line through inlining and stripped libraries
• Classify the bottleneck: branches, memory, dependency chain, ports, syscalls, waiting

A packet arrives and a decision has to leave the box before anyone else's. The budget is hundreds of nanoseconds, so nothing on the hot path may allocate, block, lock, or call the kernel. You spend your days shaving a path you have instrumented at every stage, arguing about data layout, and being certain about memory ordering because the bug you cannot reproduce costs money every day it survives. The loop also asks you to reason about probability out loud and to know enough market structure to understand what the code is for.

• Read the per-stage latency histograms from last night and pick the worst tail
• Instrument another stage; timestamps in a preallocated ring, never a log line
• Redesign a structure so a lookup is one cache line instead of four