Category: Personal Development

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.

To correct what I’ve said yesterday, the 5 ways of finding a career match are:
* live fit (career choices, location, compensation, company size)
* technology fit (candidate’s skills align and candidate has the necessary skills)
* cultural fit (candidate’s acceptance of the company’s management style, situational judgement test, personality test)
* personal fit (do I want to work with him? does he want to work in this team?)
* other factors (a blanket category for red flags and whatever you cannot disclose)

Tag: Interviewing Tips

Title: On doing take-home technical coding challenges as part of an interview process

Let me tell a fable about how I applied to the company N***. Let the name be redacted. The recruiter reached out to me via email, he found my profile on Stack Overflow. I have been actively looking for a full-time position. He said he is working on scheduling for me to tal to a VP of engineering, and meanwhile sent me a link to a technical challenge, inviting me to take it.

I spent 2 hours on the challenge and passed.

The recruiter said he’ll schedule the talk with VP for Thursday, and meanwhile wanted to talk with me himself, on Tuesday. Come Tuesday, I have to remind him to call me, after he was 15 minutes late. He rushly calls me and says that he was “just testing how much I’m paying attention” and that simultaneously “power went out” in the office and he was unable to call me. After that he asks me to talk about myself and my background. This is a red flag: if the person you’re talking with asks such a generic question, that means they don’t know or remember who you are, and you are a statistic rather than a man for them. I ask him if he’s read my resume, and he says oh yes! He remembers now, I’m the candidate with a degree from University of Michigan. The recruiter says he was reluctant, almost didn’t want to message me, because he himself went to Ohio state, with which apparently I’m supposed to have a rivalry. After that, believe it or not, the conversation degraded to such a point that there was no next step. Why? Because of the recruiter’s perceived rivalry with my school in college sports.

One of the elements of the interviewing process is the evaluation of how cohesive the team would be, with the addition of a new team member. In this particular case, I didn’t even get to talk to any team members. Upon hire, the candidate will spend no time with the recruiter, therefore there isn’t a question of cohesiveness between the candidate and the recruiter. There is, however, the very material possibility of raising a red flag: either by the candidate, or by the recruiter.

And in my application to company N***, I additionally wasted 2 hours of my time, successfully solving a technical challenge that was irrelevant. People are more important than technology, and talking to people is sometimes less tiring than doing technical work. A show-stopper in human aspect has higher priority than a show-stopper in technical aspect. For this reason, going forward, I have the requirement of talking to people before undertaking any technical challenges.