CrackML by @ml.with.umang
Interview questions / ML Math
ML Math interview question

Estimate Transformer FLOPs

Estimate the dominant compute terms of a Transformer layer as sequence length and hidden size grow.

hardconceptEvidence 34/1001 source reportTikTok

The 60-second answer

Separate projection/MLP compute from attention-matrix compute instead of quoting only O(n²). Q/K/V and output projections scale roughly with sequence length times hidden-size squared; attention score/value mixing scales with sequence-length squared times hidden size.

Build the answer in this order

1
Start with intuition

Separate projection/MLP compute from attention-matrix compute instead of quoting only O(n²).

2
Write the mathematical object

Q/K/V and output projections scale roughly with sequence length times hidden-size squared; attention score/value mixing scales with sequence-length squared times hidden size.

3
State assumptions

The feed-forward block is often a large linear-compute contributor because its intermediate dimension is several times hidden size.

4
Connect back to ML behavior

State assumptions—batch size, number of layers/heads, forward vs training—and identify which term dominates for the regime given.

A useful interview mental model

This is the shape of a strong answer—not a script to memorize.

01Definition
02Mechanism
03Trade-offs
04Failure modes
05When to use

Senior-level signal

  • Senior answers connect FLOPs to memory bandwidth and KV-cache behavior; theoretical FLOPs alone do not predict latency.
  • Discuss how longer context changes the bottleneck differently during prefill versus autoregressive decode.

What the interviewer is really testing

Whether you can connect the math to optimization, uncertainty, model behavior, and a practical engineering decision.

Likely follow-up questions

What assumption makes this approach work?
When would you choose the strongest alternative instead?
What production or data failure mode changes your answer?

Common weak-answer patterns

  • Reciting a definition without mechanism or assumptions.
  • Claiming one technique is always better without a data regime.
  • Stopping before failure modes, validation, or deployment implications.