[libraryofbabel]

Was just about to say this. As a staff engineer your position is (or should be!) so secure that you can get away with asking all sorts of “dumb” questions that more junior engineers don’t want to ask. I will also regularly say things in meetings like “I don’t understand, can you take us through that again” or “can you remind me how <xyz thing> works?”. Sometimes this makes the difference between a meeting being useful and everyone just being confused but afraid to say so.

In an ideal world, juniors would all do this too, but I don’t blame them if they don’t. So it’s very important to do it if you have the social capital.

[gmane]

One of my favorite interview questions for senior positions is "Tell me about a decision you made that you would change in hindsight." Junior level people and people who are otherwise unfit for the role will try to give answers that minimize their responsibility or (worst case) have no examples. Senior level people will have an example where they can walk you through exactly how they messed up and what they would have done differently. Good senior level candidates examine their mistakes and are honest about them.

[kyralis]

I do this for everyone, not just senior positions. "If you were to start that again today, knowing everything you do now, what would you do differently?" is a question you can ask regardless of seniority. Even if they've only done some school projects, being able to look back and say "yeah, that could have gone better from the start" is a hugely valuable signal.

The details of how I ask it might change based on seniority, but that I ask it? No.

[hosh]

It’s also true that the kind of people who are ready for staff level work are already doing staff level work. While social capital is a factor, it isn’t necessarily accumulated because of title or experience.

The idea of “disambiguation” is itself ambiguous. The way I recognize other people solving problems at a staff level is we are communicating in terms of properties, constraints and tradeoffs. Crucially, these constraints are not necessarily business constraints, but rather, constraints inherent to an architecture. For example, queuing works for ordering because it append-only, and monotonic. So as soon as you have multiple queues (such as partitioning) or try to reorder it, it also loses its ordering guarantee. Does the problem require ordering?

The first couple chapters of Roy Fielding’s dissertation goes through this. The first time I tried reading it, I did not have experience to understand. It was a slog and I got little out of it. The next time I tried reading it, it was helping me gel and articulate things I had started observing from experience. I recognized that I had previously been so focused on architectural elements and that the properties and constraints were far more important. It is this that determines what is being traded off, and antipatterns pop out. Knowing properties and constraints allows me to quickly identify problems, and start the process of disambiguation. Many of the other staff or principal engineers I have chatted with communicate along these lines.

I don’t try to ask smart questions or dumb questions. I ask questions so that I can understand properties and constraints.