Tell me about deoptimization in V8. What is it, what triggers one, and how would you actually catch it happening in your own code?
A strong answer treats deoptimization as a failed speculation guard and can name the tools that make bailouts visible on real code
So V8 compiles hot functions with its optimizing compiler, TurboFan, based on assumptions it picks up while the code runs. Like, this parameter is always a number, or the objects reaching this call site all have one particular shape. Deoptimization is what happens when one of those assumptions breaks. V8 throws away the optimized code and drops back to slower baseline execution, and it might re-optimize later. Common triggers are passing a new type to a function that had only seen one, changing an object's shape, or arithmetic that overflows the range V8 compiled for. To actually see it you can run Node with --trace-deopt, which prints each bailout and its reason, or profile and spot a hot function that's still running unoptimized. The practical advice is to keep hot functions type-stable, consistent argument types, consistent object shapes.