Categories
Management

Pride and Joy

img src: https://www.pexels.com/photo/adult-apple-device-business-code-340152/

As a leader, the two most important things you can gift your team is pride and joy. Your team should enjoy their work and feel pride in what they worked on. These are the two fundamental premises that I base leadership on. If you are able to enable this for your team, you are a good leader.

Most other leadership traits and good working environments are derived from this base. Let us take a couple of examples, and see.

  • Great teams pour their heart out into building cool stuff. Have we all not realized that, we put in our best effort if we enjoy what we are doing?
  • Growth – Most folks grow in their career paths when they accomplish significant milestones. I measure milestones by impact. And people realize significant impact that they are making, when they feel proud. Pride swells when you accomplish more and more.

It is a cyclic process too. When you enjoy the work you do, you achieve more, feel pride, which makes you reinforce the joy in your work.

Categories
Management

What do I look for, when I hire.

img src: https://vimeo.com/62395898

Interviews are a shot in the dark. You never know the state of the candidate on that one date, and deciding his fate based on how he solves a certain analytical problem, has never seemed the right thing to me.

What they have done earlier: I always ask about one project that the candidate has done in her previous work experience that she is most comfortable with. I ask the candidate, to then, go in depth, and explain to me. There are a few things that I can assess from this question:

  • Depth of knowledge: While knowledge of depth first trees and red-black trees are important, what I feel is more important, is how they have applied this knowledge. I go deep and probe into the problem, assessing, how deep the candidate has understood the problem, and the involvement with which it was solved.
  • Applied problem solving: How was the problem solved? You can test, how the candidate has applied existing algorithm techniques, or data structures to solve this problem. I ask “why so?” and “why not?” questions to see if the candidate took these decisions in an informed manner, or was she just implementing what she was told.
  • Big picture: I typically ask, where the particular piece that was developed new, or fixed, goes in the large product, or project. This gives me an idea as to how much the engineer is focused on the larger picture. The great candidates would know exactly ‘why’ they are fixing a problem, or developing a new feature.
  • Customer empathy: Yes. Every project has a customer. It might be external, or internal, but everything has an end-user. A developer in another team, consuming your API is a consumer too. I ask questions on how the candidate kept the consumer in mind. You get a lot from this question.
  • Communication skills: Was the candidate able to explain to me in a structured, lucid manner, about the problem, and how it was solved? I place very high importance in this facet. This is not to be confused with presentation skills. I do not expect engineers to be brilliant presenters (they are a few, I know of, though!). But, they should be able to communicate well enough to QA, PM, Design, and management. Else, there is huge productivity wasted here.

Attitude towards learning: Let us all agree, that, there is no one who knows everything. No one. So the best candidate, to me, is one, who realises this, and has an open slate to learn anything that is required, to do her job efficiently. There are a few ways by which I gauge this. I ask how much the candidate has learnt in the recent past. I ask about good projects and bad projects in recent past. I look for, if the candidate mentions her learnings on good and bad projects. I ask if something completely greenfield is thrown at the candidate, what would she do? Her structured methodology to crack it. I look for google, quora, online MOOCs etc.

Team player: While this seems cliche, I place a lot of important in this. I observe the candidate keenly on behavioural aspects. I ask questions such as, how the interactions with other teams such as QA, Design, PMs are? I seed sly questions such as – “These designers just don’t get technology, do they?” and observe. If there is one thing that I cannot tolerate, it is jerks. There is no place for brilliant jerks on my team. Sorry, cannot tolerate it. I will take a week more, with a slightly lesser brilliant engineer, but I would rather have fun doing it. Life is short. I want the engineer, and the team, to have pride in what they built, and jerks hamper this beautiful emotion.

Thinking process (PM interviews): I usually toss in a large green field project, such as “Growth for a Boutique Online Coffee Roasting Company”. I give the PM a few minutes alone. Once back, we work through the scenario together. I gauge structured thinking process here. I see how the PMs are making assumptions and communicating to me. I watch how the PMs react to suggestions from me. Is she accepting everything I am saying? Is she contradicting appropriately? If so, how is the dialog? Prodded deep enough, you check attitude here as well. I can sense condescension from a mile away.

I was thinking about all this today morning, and I thought, it would be good if penned these down here as well. I have been using these techniques for more than a decade for interviewing folks, and to a large extent, hit success. Sure, there were a few misses, but then, like I said, interviews are a shot in the dark. In the case of misses, you just need to realise it quickly and rectify.