This post is the twenty-fifth part of a ramble-rant about the software business. The current posts in this series are:
This post is about discovering the character of people and companies.
Most people think of interviews in the context of applying for a new job. Companies also interview each other. Or, at least, individuals in companies interview each other.
"I Don't Know"
As a hiring manager, I check for lots of things when I interview people. Since I hire ETL developers, one of the things I check for is SSIS experience. I have a list of SSIS technical questions I ask (and no, I will not post them). They range in difficulty and check for the kind of experience an SSIS developer possesses. One of the answers I'm listening for is "I don't know."
"Why is hearing 'I don't know' so important, Andy?" I'm glad you asked! No one knows everything. Well, maybe someone somewhere - definitely not me. When I'm interviewing people, I expect to encounter a topic with which they are unfamiliar. Since I know the answers to the questions I ask, I can tell when they know the correct answer and when they do not. If they take a stab at it and miss, I know I'm dealing with someone who is either misinformed or guessing. I ask good follow-up questions. If I do not get an "I don't know" I know I'm dealing with someone who does not want to admit they don't know something.
"Harry, do you know how to swim?"
What does this mean if you won't admit you don't know something? It could mean a lot of things. For me, it means you're not a good fit for my team. Why? Because we occasionally face situations where accurate information is vital. I liken these situations to "man overboard" drills. If Harry fell off the ship and cannot swim, I need Harry or someone who knows Harry to say "Harry cannot swim." This is not the situation to teach Harry the finer points of dog-paddling or treading water. It's time to find out if Harry will be able to make it until we turn the boat around, or if we need to send someone over the side immediately to help him remain afloat until we do.
If you don't know and won't tell me, you will slow us down. On my team, saying "I don't know" doesn't count against you. It's an incomplete, but honest, answer. When members of my team say it, I know they mean it.
In my presentation "Database Design for Developers," I point out the only wrong answer is "I don't know." It's wrong because we're IT professionals and are paid to know. If your choices are lying or saying "I don't know," don't lie. Say "I don't know."
"Have You Ever Lost Money?"
When I was a consultant I would interview with companies. My interview was usually with the individual(s) who would serve as my point(s)-of-contact throughout the engagement. They would usually ask me, near the end, if I had any questions. I always asked "Have you ever lost money?" If they said "Yes," I asked for non-specific details. I didn't want to know how much or to whom; rather I wanted to know that they'd done business and it hadn't always went in their favor.
This is important. It's similar to the "I don't know" points above. If I'm about to engage in business with people who always win and never lose in business, that indicates to me that they conduct business in a ruthless fashion. I don't do ruthless - at least not in business. The world is not so cut-throat as to require I thrive at the expense of others. Business has never been that way, and in a connected community it's even less so than ever before. I've been pretty hungry before, but never so much so that I intentionally engaged with people who believe they win when I lose.
I'm not advising you to run out and burn good money so you can say you've had a contract go south. I am advising you to be very careful when dealing with those who've never had this experience. Trust me on this: there's a reason.
If it were all about contracts there would be no need for lawyers and judges. It's not all about contracts. In reality, it's all about expectations and interpretations, exchanges and communication. In some business relationships, the word of an individual is a bond and the contract a formality. In others, I pay to have someone else review the contract for loopholes and gaps. Guess who gets my best rate?
"Always winning" is not sustainable.
In the SQL Server community, we all live and work in a fairly finite space. There are no longer six degrees of separation, there are usually three at most. Beware doing business with individuals who know everything and companies who always win.