(Photo by Flickr user Matias Garabedian, used under a Creative Commons license.)
I was nervous the first time I asked a candidate to make a peanut butter and jelly sandwich during an interview.
I take interviews seriously. We are interviewing each other, and irrespective of fit, they will become an ambassador of our company. Our paths will most likely cross again to boot.
At the interview, the awkward silence as I carefully placed each item onto the conference room table was the worst part:
“Jif peanut butter!”
“Will they find this demeaning?” I thought.
“Welch’s Grape Jelly!”
“Inappropriate?” I thought.
“I’m bringing a knife to a business meeting… this will go over well…,” I thought.
“Don’t forget the Wonder bread!”
“This was a terrible idea,” I thought.
Except that it wasn’t a terrible idea. “Investigate these ingredients carefully,” I said. “I want you to write down in exacting detail how to make a peanut butter and jelly sandwich. You will then read your instructions back to me, and I will attempt to construct one based on what you wrote. If you leave ANY room for ambiguity, I will seize on it, and you will fail. For example, if you tell me to: ‘pick up the knife…’ I will pick it up by the sharp end. You must explicitly state how to pick the knife up. Which hand, etc.”
Of course, they don’t “fail” for missing some innocuous step. There are other questions to consider:
- Are they are enjoying the test?
- Are they asking me questions?
- Are they digging in and looking at the ingredients?
- Oooh she’s drawing instructional illustrations!
That’s the test: Do they seek to understand the issue, engage the client and communicate effectively?
Most importantly, are they enjoying what they are doing?
Some have excelled at it. Others have found their skillsets lie elsewhere. But all felt better off for having tried. At least that’s what they told me.
But wait, one might ask, where is the code test? Where is the barrage of test questions on libraries and APIs?
Mind Over Machines stopped caring about one’s acronym history a long time ago. Five Years JSON? Three years Python? 10 years .NET? Snooze fest. Conventional development is commoditized.
This test isn’t the only thing we do in an interview, but it gives us a tremendous sense as to how someone will communicate and approach problems. Communication and problem solving are the key ingredients to tomorrow’s “software developers” – those that will graduate beyond slinging code.
The future is for those who can develop AND write AND speak AND collaborate, all while constantly determining new and innovative ways to solve business needs.