In this context, PM = product manager. As opposed to a project manager.

• How do you keep top performers engaged? Given a high-performance team, there is the challenge of keeping them around, and keeping them interested and engaged in the work they are doing - even if the work gets dull sometimes, or less than interesting. How do you motivate people, and keep them consistnetly interested in the work at hand?

I should also add here, for the benefit of the interviewee, that the behavioral questions have an implied time limit. Like in a debate. You should not spend more time than necessary answering a question. You should not spend too little time, out of fear of not demonstrating sufficient details. Effectively, I think every question is answered by two-four paragraphs' worth of oration. Answer each question in a span of 2-5 minutes, and then wait for the interviewee to ask the nexst one. Habitually, for me as an interviewee, it is a red flag when the first question from the interviewer is, "tell me about yourself." That is ambiguous and uncomfortable. It is a green flag if the interviewer first introduces himself, talks about his role and functions, to make the intereviewee more comfortable. And also as the host, it is the interviewer's task to welcome and greet the interviewee.

• What is an ideal team size? Do you have something like that in your mind? There is a rule of thumb, the two pizzas rule: you should be able to feed your team a comfortable lunch with two pizzas. Can you comment on that?

So, in technology, for me personally, a fair team size and composition is the following: 1-2 QA's, 1 designer, 1 PM, 4-6 engineers, one partner. The head count is then around 12. That sounds like 2 pizzas. Look also at the organizational social science, that states the rule of thumb of 10 people. Less than 10 people don't need a leader to agree on something. More than 10, and you're looking at increasing communication difficulties requiring a leader to resolve opinions and be able to have good direction. Mongolian army did that before it was cool: they had units of 10 soldiers, and those were batched into units of 100. Those, of course, were grouped into units of 1000.

• What are the challenges of hiring a good PM? What are the characteristics of a successful PM?

I think the last time we talked about it, the consensus was that a good PM offers a lot of flexibility, and understanding the business needs of the company. He doesn't need to be very technical, but he does need to be a good communicator, making people feel comfortable, and making sure that the team is cohesive. PM is a very interdisciplinary job.

• Have you done mentorship of junior members? How is such mentorship structured - if it is structured at all? Maybe it's always spontaneous? Talk about being a mentor to junior team members.

I'd say, a good pattern (and therefore a good answer) is to do both: structured and unstructured mentorship. Me, for example. Anyone can come to me and ask a question (or on slack), and expect some useful response or advice. If a motivated intern sits next to me, I expect him to ask questions about how to structure code, etc. This is unstructured. On the other hand, we have a company-internal blog, to which I contribute. The blog talks about interesting challenges that the company is addressing, or the structure of things that we've come up with, or how things *should* be done - a theoretic discussion. In addition to that, the company hosts weekly lunch and learn, where a team member would talk about either a problem that was recently solved, or again about how things should be done in the future, or else touch on an interesting and relevant topic. So, mentorship should be a combination of formal and informal methods.