Posted On: Sunday, 12 December 2010 by Rajiv Popat

Here is a classic (and rather stupid) Project Management question that you are bound to stumble upon if you are interviewing for the role of a project manager. The question: You have a very important deliverable on Monday. You suddenly realize on Friday that a huge task is still not done. You have a developer who is supposed to complete that task. However he seems to be having some family problems. What will you do? Will you make him stay late or come on weekends and finish the task or will you ask the management to delay the deadline?

An acquaintance who was recently asked this question snickers funnily as he describes how he "smartly" reacted to the question, told the interviewer that he will ask the developer to stay late and have him finish the problem. The interviewer as it turns out was VERY pleased with the answer and this acquaintance was offered a job after the interview ended. "I just reacted smartly, gave an shrewd response and made the idiot happy", the acquaintance of mine laughs as he tells his story of getting selected in this organization.

I could do a long rant on why this question is a hugely stupid question to ask in an interview. The question assumes that you can either be nice or productive. It assumes that there are no other developers who can pitch in and contribute. It assumes that you cannot code yourself and pitch in. It assumes a whole lot of other things. Like I said, it is a stupid question and I could do an entire post on criticizing it but instead, I thought I'd rather do the jerk conducting the interview a favor and talk about something that he was doing right during the interview.

Surprised? No Seriously! The Jerk was ACTUALLY doing something right! Honest! Want to know what it was? Grab a bag of pop corn and read on.

Interviews are complicated. They are also a completely outdated, funny and ineffective way of finding out if someone is productive or effective. Of course you can ask the person how delegates and lambda expressions work in C# and ask him to show you a real example of why you would need a delegate. That tells you if he knows his shit. It tells you that he is smart. But then most kickass companies need two things in the developers they are hiring. The developer being smart is just one of those two things. His being smart does not mean a thing till the developer Gets things done.

Smart and Get things done - Joel Spolsky wrote a book on it. Marissa Mayer, also believes it. Even Steve Yegge also believes it in his own different Kinda-Sorta-way.  

Most attempts to find both of these aspects in three two hour interviews are futile, funny and down right stupid. You can't do it. All you can do is do some basic sanity checks on your candidate, filter out the hundred other stupid candidates that fail the sanity test and hope that the one you hire works out because he knows how delegates work in c# and is able to show some signs of basic ethics and goodness during the interview. But you have no idea of his effectiveness what so ever. Stop fooling yourself!

Now, for a second, lets assume, that you were to magically find a perfect interview process which lets you measure how effective the person is can be at his work. So now you rejoice about your new found interview process, go to a bar, get drunk, eat chocolates, call your family (or do whatever it is that you do to celebrate success) and get ready to reap the rewards of this process the next day. You now have a well defined process to find out candidates who are smart and who are capable of getting things done. You are now going to have a 100% success rate at hiring amazing guys in your organization!

And then you hire your first candidate using this newly found process. And he is really smart. And he can pull new algorithms out of his ass and throw them at you every five minutes. And he is really effective. And he can get an entire million dollar project done in like a... month. And all he wants is average compensation. You celebrate! The process works!

But then on the very first week of his work you see that this new hire of yours is not effective at all. Actually, he is smart. Really Smart. He can also be really effective. But he is just not feeling it. You know, you are into building really simple, clean interfaces and simple applications that people love and this guy loves building complex enterprise applications with a zillion options and features. He thinks you are a stupid little software development shop that is not doing any serious work. You are just an insignificant 37Signals who doesn't even exist in front of an IBM which is what he wants to build software for or do a job at.

Your so-called full proof interviewing mechanism failed because it did not consider a hugely important thing most interviewers fail to consider while interviewing folks. Time to bring in the third thing into the equation.


Now, let's go back to where we started off with. This is where the Jerk interviewing my acquaintance was doing something right. By asking the famous project management interview question "will you make your team member work late when he is having some serious family issues or will you ask us to delay the deadline", this Jerk was making two points: 1. That he believed in being a Jerk. 2. That he was only looking to hire others who believed in being a jerk.

Nah! I am not talking about cloning yourself here. But if the Jerk knew that his organization was built on prickdom, he probably did not have any use for a nice guy who was willing to pitch in, help, contribute, participate, innovate, ship remarkable stuff... YAAAAWN!  He was looking for a Jerk, to control a bunch of Jerks who had also gone through similar rounds of interviews and were a perfect fit to the culture of his organization.

In being smart and hacking this interview, this acquaintance of mine, violated a basic rule. He basically told the interviewer that he was a Jerk when he was not. But then, I digress. That is not the point here. The point here is that the Jerk was doing something right. He was guarding his beliefs. He was making it very clear that you are only allowed to be a part of the organization if you were a bonafide asshole.

I am not saying that you have to be a Jerk. Neither am I saying that you have to hire Jerks. But you still need to learn the concept of protecting your beliefs just like the Jerk was protecting his beliefs. And that effectively means, that if you believe in the power of small and employees being smart individuals who when left alone do the right thing, then you should NOT be hiring anyone who is into managing your employees with a Gantt Chart.

Heck! Maybe you should be asking the same question (even though It's stupid) and kicking people right off your doorstep if they say they'll make someone who is going through a problematic time in his family, stay back all weekend to fix a stupid bug. I'm just saying.

The fundamental problem here is that most managers do not do that. Most managers even find it difficult to stand for their own believes. "Let's focus on innovation", the Vice President of engineering in your organization shouts and then the next day he adds, "Oh and by the way, can we ship these three features and seventeen reports for the road show next week?"

When this well meaning, good hearted vice president sets out to conduct interviews, how much importance do you think he is going to give to his beliefs? Enough to reject someone who does not TOTALLY believe in what he himself and the organization believes in. "He has a really good education. He comes from a different background, but he seemed smart and he is willing to learn, so I think he should be able to pick up our culture", ever heard that? That's the kind of bullshit you hear the vice presidents saying all the time.

So, protecting your beliefs is really important. But what is more important than that is having your belief's. Apple has a belief. 37Signals has a belief. And so does IBM. Even if these are completely contradicting beliefs. For example, compare what a 37Signals believes in with what an IBM believes in. But both of them protect their beliefs and guard them passionately.

The lousiest organizations are the mediocre organizations that believe in nothing and oscillate from one thought process to another depending on the market trends and what is profitable. The lousiest managers are the ones who have no opinions and are not willing to take sides.

When you are running an organization without a belief, all you are doing is hiring based on technical knowhow and some basic character evaluation. Prepare to land up with some serious conflict of interests within your employees, within teams, within divisions and within every single individual in your organization. And then when you see people bitching around and getting all political, don't complain.

After all, one of your Vice Presidents is busy drooling over 37Signals, the other wants to get your organization CMM certified and the third one doesn't even care to take a stand. He is busy oscillating between both every other week, because he is totally confused about which one gets him more business and which one gets him more productivity. And your employees are watching these Titans fight and wondering what the hell are they doing.

Maybe this sounds like an Exaggeration, but the point is, unless you have a single belief which is larger than life that governs your organization, unless you have a closed Tribe of people where the one mandatory criteria for joining the Tribe is believing in what the rest of the tribe believes in from the bottom of your heart, you are just going to keep going round and round in circles, fighting, bitching and arguing with each other every time you need to take a decision and most of your kick ass developers are going to be utterly confused about your direction, your progress and your end goal.

So the next time you conduct the interview, build a few questions that test the beliefs of the candidates and kick them out if their beliefs do not align with the beliefs you are looking for. If you can't think of any other question, start with the infamous "will you ask your team member to work on weekends when he is having a family issue" question. Instead of giving him only two choices leave the question open ended and see what he would do in that situation. See if the candidate's answer is similar (in belief and approach) to what you might have done in the situation. I know It's a stupid and a common question to evaluate belief, but then but something is better than nothing.

I'm just saying.

Comment Section

Comments are closed.