Interviewing and Hiring Stories

March 22, 2009

Since I’ve spent the last couple of posts on the hiring process, I thought I would share a couple of personal experiences.

If you were presented with a resume of someone who had a great deal of technical experience – using all of the technologies where you needed to add expertise and depth – and the resume even called out something like: “so-and-so evaluated all of the compilers on the market, and was so dissatisfied with their offerings that he wrote his own for project XYZ,” what would you think?

I interviewed this person at the request of the hiring manager – I wasn’t the one hiring – and did so over the phone because I was travelling and the hiring manager really wanted to move quickly. The phone interview started slow, and it was difficult to establish a rapport early on, and I even found myself asking this person, “Do you really want this position?”

When he responded “Yes,” I kept poking, and after one technically-oriented question, the floodgates opened! I found this person to be very knowledgeable and technically savvy. I relayed this back to the hiring manager, and by the time I returned to the office, an offer had been made to this individual and accepted. We had a new hire, someone who appeared to have all the knowledge and abilities that we needed.


You aren’t paid for what you know. You are paid for what you know and what you do. That bit about this individual writing his own compiler? That should have been something that I explored a little deeper. It turns out that it would have provided me with some very useful insight – before we made the decision to hire him. But I was younger and less experienced in those days.

This person was highly intelligent and had all the knowledge, capability, and confidence to be a strong, “A” player in the organization. But we didn’t get much out of him. Worse than that, this individual was highly disruptive to the entire team that he was assigned to. He derailed entire meetings, often quoting from his technical repertoire and providing enough information to confuse and cast doubt about the direction his team was taking. The problem was that he also failed to recommend anything to guide them.

He single-handily froze work, routinely complained about his manager, and made enough noise that senior management put him in a room to talk with him about what he needed, an open offer that included getting rid of his boss if that was required – so that he would have” room to run.” His technical knowledge was respected enough that they were willing to do this.

Despite all the complaining, this individual did not want the responsibility of making the call to get rid of his manager. He put that back on senior management. In fact, the reality of the situation was that this person had more fun tying an organization in knots rather than focusing on producing results. That was his idea of job satisfaction!

This experience is one major example of why I look for what you can do and what your accomplishments are when I conduct interviews. Being knowledgeable is great, but I look for the total value that you bring to the table, and whether you can – and will – produce results.

That person made it through the door based on deep technical knowledge. Here’s another war story of mine with someone that didn’t make it past the interview process. This case illustrates why you want to make sure that you are contributing and providing value at all times.

Several years ago, I was grabbed by our QA manager who had brought someone in for an interview that she was struggling with. She thought that a particular individual looked qualified on paper, but she was having some real trouble getting at just what this person did, and she was thinking that it was her interview technique that was a problem.

A quick scan of the resume confirmed that the individual appeared to be qualified, and there were recognition awards noted for participating in highly successful projects. I ended up sitting with her during the interview, and as the interview unfolded, I realized why my QA counterpart was struggling. She was in a state of disbelief. Here’s a slightly modified version of what transpired:

“I see that you played a major role in the ABC project,” the QA Manager said.

“Yes, I did. In fact, my manager told me that without my presence on this project, the project would have been an absolute failure.”

“Great! Tell me more about that.”

“Well, there was a problem with performance, and we tracked it back to the database layer…”

“— and you found this through testing?” the QA Manager interjected.

“Well, I didn’t actually conduct the tests, someone else on the team was testing,” the candidate responded. His high degree of confidence was also very evident.

“But you became involved when the problem surfaced?” the QA Manager asked, clearly trying to work towards what this person’s role was. Given the confidence, we both were expecting that THIS would be the where we learned what this person did on the ABC project.

“Right,” he said.

“So others approached you with the data,” the QA manager said, probing, since information wasn’t being offered. “And what did you do?”

“I didn’t do anything,” the interviewee said, with pride and self-confidence. “I called someone and told them that they needed to correct this problem.”

The rest of the interview as essentially a replay of the above, at every turn this person was “vital” to the success of various projects – and recognized as such – but this person never actually contributed by taking on any task (that we could determine) in any way! Every time we probed at something, this person always seemed to be the person contacting someone else to take action, but was never the person on the hook to do anything…

Don’t be this person! Your employment options will be extremely limited once you change bosses.