...sometimes? One of the lessons I learned from him about that level of impact is that it means the structure of your day is dictated mostly by the problem you're currently focused on. So one quarter he might spend all his time interviewing. Next quarter he might spend most of his time profiling and reading code. The quarter after he might be coding.
Next to that is a constant overhead of talks with leadership and supporting other engineering efforts throughout the company through things like doc review, chats, pairing, etc.
What he doesn't generally do is "productionize" features - code is generally exploratory in nature or fixes a serious bug (or class of bugs).
